Post By Kathie Green
Immad Akhund, our CEO and Co-Founder, moderated a panel yesterday at DeveloperWeek on the “Future of Mobile App Development,” with:
James Tamplin, Co-Founder & CEO, Firebase
Collin Jackson, Co-Founder & CEO, Apportable
Suneet Shah, Senior Product Manager, Optimizely and Co-Founder of OpenKit
Q: What app technology will be big in 2015?
Shah: The YouTube of apps will be built this year, as app streaming will be huge. There are companies like Appetize.io that are making it possible to stream apps without having to download them. The time it takes to go to the App Store and download an app has a high opportunity cost. We’ve seen app streaming functionality start to emerge in playable video ads. The two fundamental problems with mobile app development are: 1. the speed of iteration is slow, and 2. the distribution channel is controlled by the App Store.
Tamplin: For native app development, 2015 is going to be a massive year for Apple’s Swift programming language. Swift has had a meteoric ascent since it was announced at WWDC last June, jumping from a popularity rank of 65 to 22, according to a publication that measures programming language usage. iOS is where the revenue and early-adopters are, and Swift is a good bet this year. The differences between native and mobile web apps have started to erode as smart devices become more popular. With React Native, Facebook has enabled native app development in JavaScript by providing access to native UI components, making web apps feel more like native apps. React Native now has an iOS integration, which will make the “write once, run anywhere” paradigm significantly more palatable.
Jackson: Swift has come along way in the past year, and with last week’s update, it is getting really solid in iOS. You will be able to build apps on Swift not only on iOS, but on Android and other platforms.
Q: New programming languages emerge every year. What is special about Swift?
Jackson: Swift is a huge improvement on Objective-C, a dinosaur programming language that was the only option for native iOS development. Unlike other programming languages, Swift has Automatic Reference Counting, which allows you to track and manage your app’s memory usage and makes your app a lot faster.
Tamplin: It’s also much easier to learn and the number of brackets has decreased by a factor of ten! It looks like it’s from the Java family.
Q: As a developer, why wouldn’t I want to wait another year or two for Swift to stabilize before using it?
Jackson: The nice thing about Swift is it was designed to interoperate with Objective-C, so you don’t have to convert over existing legacy code bases all at once. You can start writing new bits and pieces in Swift and pull in libraries you’ve already written, which will make it easier for companies that have gigantic code bases to up Swift. With last week’s update, Swift now offers backwards compatibility, such as an automatic migration tool in Xcode. Apple worked on the Swift language in secret for many years. It’s unlikely that Swift will be completely overhauled at some point in the future because it worked pretty well out of the gate, and in the first six months, Apple responded aggressively to developer feedback on glaring issues.
Q: Have all the good mobile apps been made, or are there still tons of opportunities out there?
Shah: Asking if there’s any room left for innovation in mobile apps is like asking if we should close the patent office because we’ve invented everything already. We have not invented all the apps yet, and there are two key areas of opportunity for growth: new sensors and developing markets. New sensors spawn entirely new industries. Uber emerged when GPS became common, and accelerometers in smaller devices brought us a host of health and fitness apps.
In developing markets, the kinds of apps and services needed are different than the U.S. For example, a company in India that was recently acquired by Twitter built a marketing automation software around missed calls. Developing markets are where we’ll see the majority of smartphone growth, as the number of smartphones grows from 2 billion to 4 billion.
Jackson: Enterprise apps, not consumer apps, are where the biggest opportunities are today. Only 5% of large companies’ web-based flows have been mobilized and put into apps, and 80% of software development today is dedicated to making internal business processes more efficient. These apps are not in the App Store, so they’re not in the public eye.
Q: Should app developers worry about using servers they don’t control?
Tamplin: Firebase is a Mobile Backend as a Service, so you don’t have to worry about writing server code, you just write the code that runs on the device. We’ve seen an interesting shift in the past nine years, since the release of Amazon’s EC2 in 2006. NASA, a huge government agency, announced a year and a half ago that they would move to Amazon servers instead of their own data center. We’ll continue to see developers rely on third-party services, such as Twilio for SMS, Stripe for payments, SendGrid for email, Firebase for data storage and transmission. Developers are more comfortable running the core of their application on an open-source platform, which they can port, and for tertiary pieces of their application, they are willing to adopt proprietary APIs, like Twilio or Stripe.
Q: At what point in the development cycle is it cost-effective to switch from Mobile Backend as a Service on EC2 to a DevOps team?
Tamplin: There’s Infrastructure as a Service, Platform as a Service and Backend as a Service. Snapchat is the largest, most popular app today that runs on a Platform as a Service - specifically, Google App Engine - a level above Infrastructure as a Service. They haven’t switched yet, so as long as it’s cost-effective, versus the cost of a sysadmin or ops person, plus the cost of rewriting my application, and the cost of running all the servers, larger apps might not ever switch.
Shah: Optimizely was also built on Google App Engine, says Shah, and the question is less about cost and more about meeting new requirements to operate at massive scale with hundreds of millions of users.
Q: What tools haven’t been built that you’d like to see get built for mobile app developers?
Shah: Greater and more flexible UI controls on Android would be very helpful.
Akhund: I miss aspects of web development. It was cool that you could learn some HTML and do everything server-side; it was extremely easy, and you didn’t have to compile to make an app. You could link between apps. People are working on some of those tools, like deep linking, and I’d like to see more tools for the things we lost when we went from web to native apps.
Q: Will most developers do framework development to write once, work everywhere?
Jackson: It’s certainly possible to build amazing iOS apps without using Swift. Google’s Inbox app is written in Java. They cross-compiled their Java onto iOS and the animation is great. If you’re willing to put in the energy to write your own extremely efficient animation library in another language and profile it, you can build awesome apps in any language. The tooling and infrastructure will not be all there, as opposed to being built into the platform.
Java is not a highly-performing language in general - it’s 2-10x slower than native code. That’s why almost all of the top 100 Android apps use the Android NDK to optimize their app. The “best of the best” apps use some native code in their app, and may also use some cross-platform code. In some markets, like Europe, where iOS isn’t as popular and more people are running Android, you see a lot more hybrid apps and apps using JavaScript, because performance is pretty good on Android using those frameworks. In Silicon Valley, where devs really want to wow iOS users and get great press, it’s more common to build native on one platform and then expand their native strategy to another platform.
Q: On the web, we had extremely easy to plug in third-party JavaScript. On native, plugging in an SDK can crash your whole app, you have to deploy a new version and wait for App Store approval. Is SDK fatigue a real issue, and what’s the solution?
Shah: SDK fatigue is a real problem. On a web app, you can easily turn off a JavaScript snippet. When you deploy an SDK and your app crashes, you have to pull it from the App Store. Before adopting an SDK, talk to other customers and audit what you put in your app. If you’re only using 3 SDK’s of the 15 in your app, take out the other 12. On iOS, use CocoaPods, and on Android, use Maven to manage your dependencies. Specify the exact version of the SDK you want to use. The big problem with SDKs is interoperability. Push your vendors to build integrations to improve interoperability. At Optimizely, we built an integration with Mixpanel, a competitor. The SDK-to-SDK integration ensures every build of the Optimizely SDK works with Mixpanel. Optimizely also build a kill switch into the SDK, so if a customer has a problem with the SDK, they can remotely turn it off without pulling their app from the App Store.
Q: Today, you have to work in iOS, Android, and server-side code, but some products have also made app development easier. Is life getting harder or easier for app developers?
Tamplin: On the whole, life continues to get easier, as the trend of abstraction prevents you from having to think about things lower down the stack. When you hit massive scale or need something really custom, it’s time to drop down a level in the stack.
Q: Will JavaScript everywhere - on the server, on the client, on native - happen?
Tamplin: It’s labor efficient for it to happen. Programmers’ time will be more costly, so the market is incentivized to make it happen. Right now, you still get the highest quality if you build for native.
Q: How are we going to solve the UI nightmare, including multiple screen sizes, rotating landscape vs. portrait?
Shah: Android does a better job from the beginning, as auto layouts on iOS don’t work for complicated layouts, says Shah. There are prototyping tools that allow you to write CSS and it builds a native-looking prototype. In the next few years, those kinds of tools will turn into a flexible layout language.
Akhund: Flexibility has costs to it, so it’s a trade-off between precision and flexibility.
Jackson: Regarding flexibility, Apple isn’t incentivized to work with Android, but Google wants to make it easier for users to use their products regardless of the hardware you own. It’s possible Google will want to invest in making tools for great iOS development, even though Android is their home platform.
Q: What do you think about a single API to access multiple third-party APIs, specifically Google Drive, Dropbox, Facebook, Instagram?
Akhund: We do something similar with mobile advertising, providing one API to access multiple mobile ad networks. In an industry like cloud data storage, with Dropbox, Google Drive, and iOS Cloud, where there are more than two or three dominant providers, there’s a good opportunity to build an API that abstracts the services. Most app developers shouldn’t have to do the same thing twice. One great thing about app development is the people who feel the pain are the people who can solve the problem and open-source it for everyone to use.
Q: If you were going to build for something new, like the Apple Watch or Oculus, what platform is worth investing in now?
Shah: I would build for the Apple Watch, which is more likely to get adoption quickly.
Tamplin: I would build for Oculus, as VR will be massive.
Jackson: If you want to build for something that will have millions of users in the next year, you should build for Apple Watch. Oculus will be a lot more fun, but will require a lot of resources and artists to make it visually impressive.