Why we are building the Ionic Platform
June has been a huge month for the Ionic team, with announcements of Ionic Push, Deploy, and Analytics, along with Ionic Jobs and the upcoming Ionic Market. I’m incredibly proud of and humbled by the team we have here and their ability to focus and ship like there’s no tomorrow! 
In the course of those announcements, we’ve received a ton of questions about everything from pricing, to how the Ionic Platform compares to other services and where we’re taking it. Instead of trying to respond to everyone individually, I’d like to address them here in this post.
I think it’s important to start with why we’re even building the Ionic Platform in the first place, and why we are so certain it fills a crucial gap in the market.
“No Web Views”
One of the things that shocked me when I started to explore the potential for a web-based mobile SDK back in 2013 was how antagonistic the mobile development market was towards hybrid apps based on open web technologies. Everywhere I turned, companies were bragging about how their solution was “100% native” with “no clunky web views” and “no CSS or HTML.” Many of these were mobile service providers offering solutions for push notifications, analytics, a/b testing, design, and development.
This was in sharp contrast to many of the individual developers, small and huge businesses that I talked to that really believed in the dream of using web technology everywhere, and especially on mobile. To them, it wasn’t a second-class option, it was better than doing pure native development.
These developers really wanted to be able to build mobile apps with the web stack. They wanted to put their web developers and designers to work, instead of having to find unicorn native developers. They wanted to use the most widely used and known technology stack in the world, and they definitely wanted to release on all major platforms on day one…but were struggling with the right frameworks, tools, and services to do that.
I realized that the vast majority of the mobile dev space had a huge blind spot and was in utter disbelief that anyone would want to build a serious mobile app with browser technologies, so they weren’t catering to the needs of hybrid devs at all. I thought Paul Graham’s What You Can’t Say post was quite fitting here: Hybrid app dev was taboo, and in many circles was not at all “cool,” so a lot of startups were ignoring it at best and fighting it at worst. And that drew me to it.
Our intense focus on hybrid developers was validated once Ionic started gaining traction, Apple and Google started featuring Ionic apps as best-in-class, and developers came to us asking for recommendations for push notifications, databases, app servers, analytics, and everything in between. They just weren’t finding what they needed from the mobile development space that only cared about developers building apps with the native SDKs, languages, and controls.
It seemed there was a huge gap in this quickly growing market, and we were inspired to fill it.
How the Ionic Platform is different
The mobile development services market is fairly mature at this point, especially if you’re building with the core vendor stacks and using their provided UI controls. So, we’ve seen a proliferation of services for push, backend code, databases, analytics, A/B testing, beta testing, etc.
The issue is that, as a developer using the browser as the runtime environment for your app, very few of these services have solutions targeted at your use case. Some have nothing for JS and HTML/CSS, and some solutions just target desktop websites (think Google Analytics).
At a high level, we want to bring these services to those who choose to build their entire app in the hybrid browser environment.
Take analytics, for example. It’s hard to find an analytics provider that automatically listens for UI events for mobile web apps. It’s hard to find JS analytics tools that realize you are building an app for the app store, not a desktop or responsive mobile site (where we don’t care about things like referrers or search traffic keywords). Ionic Analytics embraces this use case.
Push can automatically navigate in your app with the proper payload, since it understands Ionic’s router. The whole payload for push is being expanded in this way, to do a lot of magic for you through the web and Ionic environment.
The entire Deploy service wouldn’t exist without the web stack, since it’s not feasible to replace the entire UI for a native app remotely. Since we’ve embraced the web stack, we can fetch assets and update the UI remotely without resubmitting (in a way that Apple actually allows, for apps built inside the provided Web Views).
Going further, we also believe that AngularJS gives us many interesting ways to build powerful features much more quickly than before. With that in mind, our A/B testing feature will use the power of Angular directives to make it incredibly easy to toggle between UIs. Think ng-switch, but with variables set on the backend!
These are just a few examples. The point is that Ionic’s services embrace the fact that your app is built with web technologies in a way that the rest of the mobile development market just does not. Beyond that, we are going to integrate the platform services tightly with Ionic, so if you pick the Ionic SDK for the frontend of your app, the services will Just Work.
I do want to stress that we will never force you to use the platform for your app. We want Ionic to offer the best set of mobile services out there, but if there’s something that is a better fit for your app, we want you to be able to use it, and then we want to figure out how to make ours better!
Pricing
We’ve gotten a ton of questions about pricing. Since Ionic services are largely just in alpha still, some devs are understandably anxious about investing in them, without knowing how much it’s going to cost in the future.
To be 100% clear, we will be charging for Ionic services in the future. At some point, Ionic needs to generate revenue, in order to build the strongest possible company and to keep making hybrid developer’s lives better. Since we want the SDK to stay free forever, we plan to build the business on the platform, which better aligns us with devs: you get free tools to build great apps, and as your app is successful, we can help it scale. I don’t think this comes as a shock to anyone, and many of you already tell us that you want to pay us money, which we always love to hear :P.
While charging is a given, we are a well-funded, VC-backed company, and we are operating with the vision that right now, the best thing we can do is to make Ionic and the platform as frictionless as possible to use and to grow with. We have plenty of cash in the bank, with the express purpose of focusing on building a great product for all of you. It’s intentional.
So, with that said, we have made a number of decisions about our pricing already.
First, we will absolutely have a free/dev tier for every service we release. We know many devs are in long development cycles and haven’t released or hit traction with their app. We want to make sure that you can build and test and work to get off the ground without worrying about the cost of using the Ionic Platform to do that.
Also, we’ve decided that we want to have different pricing for each individual service. We think Heroku and AWS do this really well: You can pick and choose from various databases, add on services, etc., but you only pay for the usage on that specific service.
Billing will be per-app, so an app built for a client can be transferred to them, and their card will be the one that gets charged. You can build as many apps as you want on the platform without paying anything, until usage on a specific service for a specific app passes a threshold.
The challenging part about actually figuring out what those tiers are is that we aren’t yet sure what’s appropriate for free/dev mode and beyond, and I want to make sure we don’t shoot ourselves in the foot until we’ve learned how the services are used.
We are operating under a simple assumption: We only want to make money if your app is successful. We want it to be a mutually beneficial relationship, where you can scale up over time, and we can continue to provide a robust and well-supported service for you to do that.
Our plan is to release pricing information for each service that goes into beta, so you know what you will be paying once we go into production. Push will most likely be the first service to do that, and we plan to make it competitive with the rest of the push services market.
Getting back to coding
I hope that addresses some of the questions we’ve gotten since we announced the platform services. If there’s anything lingering still, please feel free to leave a comment or email us.
The point I want to leave you with is that we on the Ionic team strongly believe the mobile services and tools market is not doing nearly enough to cater to the huge and growing demand for hybrid app development. We are so certain that hybrid apps built with Ionic will become an increasingly large portion of the apps in the app stores, and developers will need more and more help in making these apps do useful things and scale up to millions of users.
We hope you find the services we are rolling out useful and compelling enough to use, but if they aren’t, please let us know!, so we can fix that. We are working hard to bring our alpha services into beta as quickly as possible and to move into stable production mode soon after that!
