Forem: Max Lynch

10 Reasons to Choose Ionic for Mobile Development

Max Lynch — Thu, 22 Jul 2021 18:47:57 +0000

The Ionic stack makes it easy to build iOS, Android, Desktop, and Progressive Web Apps using standard web technology. There are a lot of options for cross-platform mobile and web app development, so when should you or your team consider using Ionic?

Here are 10 reasons you might want to choose Ionic:

1. You’re a web developer

One of the best reasons to choose Ionic is if you’re a web developer and want to stay in the web development world. The Ionic stack is built on standard web development technologies meaning you can build the majority of your app directly in a browser and use standard browser development tools and technologies, while still deploying and building a traditional native app.

Other cross-platform toolkits don’t use the web development stack so aren’t the best fit for web developers.

2. You are building a new app dev engineering team

Because the Ionic stack is focused on web developers, it’s the easiest cross-platform technology to hire for because there are considerably more web developers in the world than any other mobile technology. Any web developer can easily learn to build apps using the Ionic stack and it will be the most familiar to them, and have the best compatibility with popular web frameworks like React, Angular, and Vue.

And hiring web developers means they can then develop for mobile, desktop, and web without the need to hire specialist teams for each platform.

3. You’re an enterprise (or work at one)

Ionic is the only cross-platform development stack that has Enterprise support and integrations for teams building employee and customer-facing apps. Ionic offers dedicated support, security features like Biometrics and Single Sign-on, and cloud services for remote app updates, app builds, and app store distribution.

Ionic is the industry leader in enterprise app development with hundreds of Fortune 1000 customers, and customers love it.

4. You have existing web experiences and investments

Because the Ionic stack is based around standard web development, it’s the only cross-platform solution that supports bringing existing web experiences, libraries, and other web code into an app.

This is particularly important for enterprises or teams with a heavy web presence that want to bring those experiences into existing apps, such as traditional native apps.

5. You want to join a massive community of developers

Building apps with popular technologies makes it easier to hire for, easier to find partners, and easier to find resources on the web as you build your app.

The Ionic developer community is massive, with millions of developers around the world having built apps on the stack. Passionate community members build and share tutorials, add-ons, templates, and more, and developers can find help on the Ionic forum and Stack Overflow.

But Ionic is unique in that the community isn’t just limited to Ionic’s bubble. Because Ionic is based on standard web technologies, the addressable community goes beyond Ionic and overlaps with the broader web development community, such as the React, Angular, and Vue communities. This is critical when considering building out app dev teams because an Ionic team can be built with web developers, but other technologies require hiring specialists on languages and technologies that are not widely used.

6. You’re on a tight deadline

We often hear from teams who spent months building their app using a different technology, failed to hit deadlines, and then switched to Ionic and had the new app working and surpassing the old one within weeks.

Ionic is highly productive because the web is highly productive. And one app can run on multiple platforms so development time can be upwards of 3-4x faster than traditional native development!

7. You want your apps to be on iOS, Android, Web, and even desktop on day one

Ionic apps run anywhere the web runs, and with the same code! And Ionic has official support for iOS, Android, Desktop, and Web, so teams can hit the ground running — targeting all these platforms and their respective user bases at launch.

8. You want to be able to benefit from both app store and web traffic

Because the Ionic stack is based on web technology, teams can target the web and build a high-performance Progressive Web App (PWA).

This means teams can reach users both in traditional app stores but also on the web and through Google search to maximize reach and have the best chance for a successful app project. We’ve talked at length about how the Ionic stack gives you the best distribution optionality of any cross-platform technology in the market.

9. You already have web developers on your team

If you already have web developers on your team or at your company, using the Ionic stack is a no-brainer! Web developers can easily become mobile developers by learning to use the Ionic stack, including Ionic’s 100+ mobile-optimized UI components and the native runtime that provides hooks into functionality on each platform. Ionic also supplies the means to build and deploy those apps.

10. You’re a student or new to app development

Ionic is the most accessible platform for cross-platform app development. If you’re familiar with basic web development you can build real mobile apps (and desktop + web apps) today!

Learning Ionic requires learning a few new HTML tags, some new JavaScript APIs for native functionality, and then just building your app using your framework of choice (React/Angular/Vue/etc).

And the best thing is you continue to build your web development skills at the same time and don't have to change your technical career focus.

Get started today

There you have it, ten good reasons you and your team might want to adopt Ionic.

If you're interested in building cross-platform apps using Ionic and modern web technologies, Get started with Ionic today.

App store or web? Why not both!?

Max Lynch — Wed, 09 Jun 2021 16:12:23 +0000

Most app development technologies force teams to make hard decisions about where they will distribute their apps, usually either app stores as a native app or the web as a Progressive Web App.

Building a native Swift (iOS) or Kotlin (Android) app, for example, obviously limits teams to just those respective platforms. But others have more subtle restrictions. Xamarin enables you to build for iOS, Android, and Desktop, but not for the web, meaning no access to a major chunk of mobile traffic and app-consuming users. React Native’s View elements can be abstracted to have the same API on the web but you will need to write completely separate view code for it, avoid using certain standard web features, and use different calls for certain APIs, so it’s an additional investment. Flutter can be used to build iOS, Android, and Web apps, but its web support requires multiple MBs of code for users so it’s not appropriate for high-performance Progressive Web Apps and speed-sensitive web sites like those that depend on search engine rankings and SEO.

Capacitor, a universal app runtime, avoids these tradeoffs by targeting one universal runtime (the web), and giving you maximum optionality for where you distribute the app that you build. You can deploy your app with one codebase anywhere your users are, even if that happens to change! That might mean the app stores today, but it could mean the web and desktop tomorrow.

What Optionality Looks Like

I was recently helping a team think through an app project they were going to deploy to the app stores on iOS and Android. They were using Capacitor with React, using a home-grown UI based on Tailwind.

During development, the team decided that they wanted to have a strong web portion to their app in order to easily acquire users, benefit from instant access and SEO on the web, and avoid app install bounce risk (meaning, the user leaves without ever installing the app, which is very common in the mobile world!)

Since their app was built with Capacitor, utilizing Capacitor’s cross-platform APIs, they could simply deploy the same app with the same code as a Progressive Web App hosted on a platform like Vercel or Netlify.

And this decision didn’t preclude them from also shipping a native iOS and Android app. They decided that they would unlock some additional features that depended on native functionality missing from the browser environment for users that were “activated” and likely to stick around.

Doing so in Capacitor was straightforward because Capacitor APIs are identical on iOS, Android, and the Web, and Capacitor comes with a number of utilities for adding conditional platform-specific code if desired.

Why this Matters

For new projects, the greatest risk isn’t technical but rather that no one uses your app and it never gains meaningful traction or scale. One of the best ways to avoid that is to reach the broadest possible segment of your target audience on day one.

For most companies, their audience isn’t on a single platform, form factor, or environment (such as mobile or web). This is especially true for consumer and enterprise consumer companies. In fact, there’s a good chance a majority of users aren’t even on a platform that you, the developer, actually use primarily (such as Android if you’re an iPhone user or web apps if you’re in the US and used to installed native apps).

Having optionality might mean the difference between your app project failing or succeeding, and nothing could matter more than that.

How does this compare to Progressive Web Apps?

One of the things to think about when building a Progressive Web App not with Capacitor, is that it will constrain your app to running only in a traditional browser context. This means it will only be accessible on the web and not have the option to access native APIs that don't have a browser analog since it cannot be distributed in popular mobile app stores.

Thus, the decision to build a Progressive Web App can also be limiting. But in this case a very straightforward way to add native iOS and Android support is by installing Capacitor into your Progressive Web App.

Capacitor has full Progressive Web App support and apps use the same Capacitor API calls regardless of the platform they are running on. This makes it easy to bring it to iOS and Android with the same code.

In that sense, Capacitor is "web app virtualization layer" that enables standard web apps to run anywhere with the same APIs, regardless of the "host" platform underneath.

Who's using Capacitor today?

Capacitor is growing quickly (100% YoY) and is installed over 500k times per month. Teams at companies like Burger King, Tim Hortons, Workgrid (Liberty Mutual), and Fidelity, to name a few, are all using Capacitor to enable their web teams to deploy iOS, Android, and Web apps with the same code.

Capacitor was also rated #1 in satisfaction among mobile development tools on the latest State of JS survey.

Capacitor was created by the team behind the popular Ionic Framework as a replacement for Cordova for deploying modern Web Native apps on iOS, Android, Desktop, and Web.

Get started

Getting started with Capacitor and building full distribution optionality into your mobile-enabled web app is as easy as installing the Capacitor library and running a few commands.

Get started with Capacitor today and follow us for more resources and updates on the project!

Building a better Web View for mobile apps

Max Lynch — Tue, 18 May 2021 15:02:21 +0000

Web Views are among the most widely used components in mobile apps for good reason: most apps need to incorporate some internal or external web experience at some point.

Because of this, Apple and Google provide basic Web View controls out of the box: iOS with WKWebView, and Android with WebView (there are other options on Android but this is the primary one most apps use).

Unfortunately, using these Web Views is anything but simple, and native developers are stuck reinventing the wheel every time they need to use one of these Web Views in their app. Luckily, that pain is coming to an end. Read on to learn about our take on a better drop-in Web View for iOS and Android native app developers.

The Use case for Web Views

Web Views feature prominently in many apps. Some apps are built entirely around a single primary Web View instance, and other traditional native apps selectively display and embed Web Views to bring in web experiences.

For apps where most of the functionality and content is built in the Web View, the use case for Web Views is obvious. I don’t want to spend more time talking about that use case here but tools like Capacitor and Ionic Framework excel at this and are widely used.

For traditional native apps, the use cases for embedding web experiences might vary from from embedding an existing web experience such as a mortgage application or a survey, to displaying web-based authentication forms, to hosting prototype web experiences before porting to native.

Generally, the more established the company, the larger their web development teams, and the more prominent that company is on the web, the more likely they will need to bring in web experiences into their mobile app at some point in time.

The Problem with Web Views Today

Generally, Web Views provided by Apple and Google are spartan and bare bones. Nearly every native developer that we’ve talked to has expressed annoyance at extending the stock Web View controls and then maintaining a fairly complex set of code to host web experiences in the app. Thus, the problem with the stock Web Views is that they just don't do enough and don't cover the surface area of what native developers typically need them to do.

I have first-hand experience with this as the creator of Capacitor, which is essentially a supercharged Web View for hosting web apps that need to interface with existing native code. Capacitor is many tens of thousands of lines of code that wrap the core Web Views available on each platform and add a number of features, like:

An API for adding new native “plugins” that expose new Web APIs to web developers based on custom native code, and do so in a controlled fashion and with a web-developer approved API (promises, typescript, etc)
A high performance bridge for communicating between web and native and keeping track of invocations and returning results back to the caller
Handling references to assets to host web content offline and correctly stream data for Web HTML controls like video and audio (surprisingly tricky).
Marshalling data between the native and web layer
Managing native elements such as alert dialogs, keyboard, status bar, scroll regions...all while correctly handling orientation changes
Handling delegate methods for navigation, load, errors, permission requests, and other general housekeeping.
Updating embedded web experiences dynamically and out of band with the slower native release cycle

And then doing this on both iOS and Android (on which even more code and complexity is required). And this list is not nearly exhaustive!

It seems like every meaningfully large native app ends up implementing a subset of the features above, which is no small task!

Building a better Web View

It took many months to build the first version of Capacitor due to the complexity required in building a robust Web View wrapper with the above features, and I never want another developer to have to go through that again.

Sadly, almost every native app developer does have to go through this today, and then has a bunch of complex, custom code to maintain. All that when they could have just imported a stable, well maintained, feature-rich Web View control and got back to the fun part of building their app.

When we realized that what we had with Capacitor could be pulled out to help native app developers everywhere, we knew we were on to something: a much better Web View for native apps.

Announcing Ionic Portals

We’ve been working on bringing the Web View technology behind Capacitor to native apps and native developers everywhere, and we are taking the wraps off the first iteration of that product today: Ionic Portals.

Ionic Portals is a drop-in Web View component for native apps that handles all the messy, annoying parts of using a Web View in a native app. Developers can host multiple different web experiences through different “portals”, and isolate them, selectively exposing custom native functionality that each one needs. Teams can remotely update and deploy new web experiences dynamically to deploy new features and tests in realtime and without disrupting the native app release process.

Ionic Portals uses the same technology currently deployed in major consumer apps like Burger King, Paylocity, H&R Block, Aflac and more, but distributed as a drop-in control for existing native apps.

And on top of all this, Ionic Portals is maintained and supported by us, so you have one less component to have to maintain in your app.

We’re currently working with a few teams who are desperate for a better Web View control in their native apps. If you’re interested in trying it out and sharing your feedback as we built out the product, we’d love for you to get in touch. Visit the Ionic Portals page to see a demo and learn more about our take on a dramatically improved Web View for native apps.

Build Mobile Apps with Tailwind CSS, Next.js, Ionic Framework, and Capacitor

Max Lynch — Mon, 01 Feb 2021 15:24:54 +0000

A very popular stack for building responsive web apps is Tailwind CSS and Next.js by Vercel.

Tailwind, a utility-first CSS framework that replaces the need to write custom class names or even any CSS at all in many cases, makes it easy to design responsive web apps through small CSS building blocks and a flexible design foundation.

Next.js, a React framework for building high performance React apps, is one of the leading environments for building production React apps on the web.

As these technologies have grown, they are increasingly used together for web app development (in fact, Next.js is working on an RFC for official Tailwind integration). This has prompted many users of these projects to ask whether they can be used to build mobile apps, too.

Turns out, they can! And they make a great fit for cross-platform mobile development when paired with Ionic Framework and Capacitor.

As I started playing with these technologies, I realized that each had a natural fit in a combined mobile stack, and I wanted to put together a solid starting foundation for others interested in building real iOS and Android apps using these technologies.

If you're confused by all the project names and how they work together, don't worry, I'll break down each part of the stack each project is concerned with, along with some visuals and code samples demonstrating how all the projects work together. At the end I'll share a starter project with these technologies installed and working together that can form the foundation of your next app.

The Stack Visualized

The above is a live screenshot of a React app built with Next.js that is using Ionic Framework and Tailwind for the UI experience, and Capacitor to natively deploy that app to iOS and provide access to any Native APIs the app uses.

There are a lot of projects working in tandem to provide the full experience here. To visualize it, I've tried to overlay the different layers and how they correspond to each project in this diagram above.

We can see that Capacitor is concerned with the entire app and device layer of the app, Next.js is concerned with the entire web/React app our code and UI is running in, then Ionic handles the "platform UI" including navigation toolbar (including system title and toolbar buttons) as well as the bottom tabs.

Finally, Tailwind is used to then style and customize the content of each page, which is where the bulk of the app-specific styling will occur.

Mobile UI and Native Runtime

If your experience building with web technologies is primarily for desktop or responsive sites, you might not be familiar with mobile-focused libraries Ionic Framework and Capacitor.

Ionic Framework is a cross-platform, mobile-focused UI library for the web. It provides ~100 components that implement platform UI standards across iOS and Android. Things like toolbars, navigation/transitions, tabs, dialog windows, and more. The big draw is those components work on the web and work in frameworks like React, Angular, Vue, or plain HTML/CSS/JS.

Ionic Framework is highly popular and powers upwards of 15% of apps in the app store.

Historically, Ionic Framework would be paired with a project like Cordova which provided the native iOS and Android building and runtime capabilities. However, most new Ionic Framework apps use Capacitor for this part of the stack.

Capacitor is a project built by the team behind Ionic Framework focused on the native side of a web-focused mobile app.

Capacitor provides a plugin layer and runtime that runs web apps natively on iOS, Android, Desktop, and Web, and provides full access to device APIs and features (including extending the web environment by writing additional native Swift/Java code).

As such, any popular web technologies and libraries can be used to build mobile apps with Capacitor, and then deploy the same apps with the same code to the web and desktop.

And, to top it all off, Capacitor was just rated the second highest in satisfaction among popular Mobile & Desktop Tools on the State of JS 2020 Survey! If your last experience with this mobile development approach was with Cordova, we think you'll find Capacitor to be a big improvement.

Introducing the Next.js + Tailwind CSS + Ionic Framework + Capacitor Starter

Now that you have a sense for how these technologies all work together to make it easy for web developers to build mobile apps, let's take a look at a real demo and starter project (GitHub repo):

Let's take a look at the main Feed page (seen above in the screenshot) for an example of how the different technologies in use work together:



import {
  IonPage,
  IonHeader,
  IonToolbar,
  IonTitle,
  IonButtons,
  IonButton,
  IonIcon,
  IonContent,
} from '@ionic/react';
import { useState } from 'react';
import { notificationsOutline } from 'ionicons/icons';
import Notifications from './Notifications';

import Card from '../ui/Card';
import { getHomeItems } from '../../store/selectors';
import Store from '../../store';

const FeedCard = ({ title, type, text, author, authorAvatar, image }) => (
  <Card className="my-4 mx-auto">
    <div>
      <img className="rounded-t-xl h-32 w-full object-cover" src={image} />
    </div>
    <div className="px-4 py-4 bg-white rounded-b-xl dark:bg-gray-900">
      <h4 className="font-bold py-0 text-s text-gray-400 dark:text-gray-500 uppercase">
        {type}
      </h4>
      <h2 className="font-bold text-2xl text-gray-800 dark:text-gray-100">
        {title}
      </h2>
      <p className="sm:text-sm text-s text-gray-500 mr-1 my-3 dark:text-gray-400">
        {text}
      </p>
      <div className="flex items-center space-x-4">
        <img src={authorAvatar} className="rounded-full w-10 h-10" />
        <h3 className="text-gray-500 dark:text-gray-200 m-l-8 text-sm font-medium">
          {author}
        </h3>
      </div>
    </div>
  </Card>
);

const Feed = () => {
  const homeItems = Store.useState(getHomeItems);
  const [showNotifications, setShowNotifications] = useState(false);

  return (
    <IonPage>
      <IonHeader>
        <IonToolbar>
          <IonTitle>Feed</IonTitle>
          <IonButtons slot="end">
            <IonButton onClick={() => setShowNotifications(true)}>
              <IonIcon icon={notificationsOutline} />
            </IonButton>
          </IonButtons>
        </IonToolbar>
      </IonHeader>
      <IonContent className="ion-padding" fullscreen>
        <IonHeader collapse="condense">
          <IonToolbar>
            <IonTitle size="large">Feed</IonTitle>
          </IonToolbar>
        </IonHeader>
        <Notifications
          open={showNotifications}
          onDidDismiss={() => setShowNotifications(false)}
        />
        {homeItems.map((i, index) => (
          <FeedCard {...i} key={index} />
        ))}
      </IonContent>
    </IonPage>
  );
};

export default Feed;

As we can see, we use Ionic Framework controls (IonPage, IonHeader, IonContent, IonToolbar, etc) for the structure of the page (these controls implement iOS and Android platform-specific styles and navigation/transition behavior), then we use Tailwind for the page content that is where our custom design lives (which will tend to be in IonContent).

If we look at another page that is just a simple list, we see that we don't use Tailwind at all, because the user would expect this page to be a standard iOS/Android list and toggle button (code here):

So, we tend to use Tailwind more for pages with a lot of custom design and assets. That's by design. Generally when building a native mobile app, we want to use platform conventions as much as possible, especially for experience and performance-sensitive elements like Lists, Toolbars, Tabs, and Form inputs. However, for the Feed page, which has a pretty custom UI experience, we end up getting a lot of mileage out of Tailwind.

So, in general, the way to think about when to lean more on Ionic Framework and when to lean on Tailwind is when your UI experience will heavily use typical mobile UI elements (prefer Ionic components) or when it will be more custom (prefer Tailwind).

Finally, this starter also comes with a few small opinions around folder structure and state management. For state management, the library pullstate is used which is a simple yet powerful state management library with a hooks-based API (I wrote more about it here). If want to use something else, removing it is easy.

Deploying to iOS and Android

The app can be easily deployed to iOS and Android using Capacitor and its local CLI tools. After running npm install, you'll have the npx cap command available, which enables a native development workflow:

To add an iOS or Android native project:



npx cap add ios
npx cap add android

Then, to build the Next.js app, export it, and copy it to the native projects:



npm run build
npm run export
npx cap copy

This command is needed every time the built output changes. However, you can enable livereload during development (see the README for more info).

Then, you can launch Xcode and/or Android Studio to build and run the native project:



npx cap open ios

npx cap open android

Next steps

If you've been interested in building mobile apps using popular web dev projects like Next.js or Tailwind, hopefully this starter provides inspiration and a solid foundation for building your next app using web technologies. It's worth mentioning this exact same approach can be used with other UI libraries (like material, bootstrap, or your own!).

When you're ready, dig into the starter project, follow the Capacitor and Ionic Framework docs, and get building!

The Easiest Way for Web Developers to Build Mobile Apps

Max Lynch — Tue, 05 Jan 2021 15:45:13 +0000

For web developers interested in building Mobile apps, there's a plethora of options today. Developers can choose between projects like React Native, NativeScript, Cordova, Ionic Framework, and Capacitor, just to name a few.

Given the large number of options, it's not always clear what would be the most appropriate for a web developer looking for a familiar web-based development experience.

With that, I'd like to make the case that Capacitor (optionally with a mobile-focused UI framework like Ionic Framework) is the most natural and easiest way that web developers can build mobile apps.

"Electron for Mobile"

Electron is a massively popular solution for building cross-platform desktop applications using standard web technologies. Web Developers can use the standard HTML, CSS, and JavaScript they use for web apps, including any popular libraries like React/Angular/Vue, Tailwind, or Material UI, and turn those apps into powerful desktop apps.

This simple formula has turned Electron into one of the most popular cross-platform toolkits. Today, Electron powers many popular apps, like Slack and VS Code.

If you ever find yourself asking "what is the analog to Electron but for mobile apps?" the answer is Capacitor.

Like Electron, Capacitor takes a standard web app that runs in the browser, and extends it with access to powerful native APIs and Native UI (like Camera and Filesystem). These APIs work on iOS, Android, Web, and Electron.

While Electron bundles in a "web view" through Chromium, Capacitor uses the standard embedded Web View native controls available on iOS and Android. This means that Capacitor doesn't suffer from the same bloat issues that Electron does.

The net effect is that Capacitor is really a sort of "Electron for Mobile."

What about React Native or Flutter?

You might be asking yourself: why isn't React Native (or Flutter) the "Electron for Mobile?"

The reason is that React Native and Flutter do not use a standard web browser environment to run an app. Rather, they are abstractions over system UI controls and APIs to provide a "web-like" experience building apps rather than a true web environment. Both require code specifically written for each platform, and cannot use web-specific libraries or code.

This is important, because it means the shortest path for a web developer to build a mobile app is Capacitor, hands down:

An Example

Let's take a simple example of a web app using Ionic Framework with React for a native-quality mobile UI experience, and Capacitor to deploy it natively to iOS, Android, and web.

Taking a look at the code, we see that it's just a plain React app that happens to use Ionic Framework for its UI components. For example, developers familiar with React Router should find the JSX used to build the Tab layout familiar.

Then, by running some Capacitor commands, we can bundle the app and run it right in Xcode:

Since our app is just a plain React app, we can also run it directly in the browser and even deploy it as a Progressive Web App to any static web host:

Finally, Capacitor ships with a JS module, @capacitor/core, that provides a consistent, cross-platform approach to accessing device functionality.

For example, to access the Filesystem API, we can use the same code on iOS, Android, Web, and Electron:



import {

  Plugins, 

  FilesystemDirectory,

  FilesystemEncoding

} from '@capacitor/core';

const { Filesystem } = Plugins;

async fileWrite() {

  try {

    const result = await Filesystem.writeFile({

      path: 'secrets/text.txt',

      data: "This is a test",

      directory: FilesystemDirectory.Documents,

      encoding: FilesystemEncoding.UTF8

    })

    console.log('Wrote file', result);

  } catch(e) {

    console.error('Unable to write file', e);

  }

}

Who's using Capacitor?

Capacitor is being used to power major apps today. Companies like Burger King, Popeyes, and the BBC (who wrote a great article about their use of Capacitor to build universal, web-native apps) are using Capacitor build apps across iOS, Android, Web, and Desktop with one code base and standard web technology.

Capacitor is also the new native foundation of Ionic Framework, which powers over 15% of all apps in the app store today.

Getting started with Capacitor

If you're familiar with Electron, Capacitor should feel very familiar to you. It's installed like a typical JS module directly into your app, and a local CLI tool is added for copying your web app to native iOS and Android projects, as well as syncing and installing new Capacitor plugins.

To get started with Capacitor, check out the official Capacitor Docs and get building!

What is it about Vue?

Max Lynch — Mon, 19 Oct 2020 16:06:24 +0000

On the heels of announcing official Vue support for Ionic Framework, I wanted to dig into why we decided to officially support Vue here at Ionic, and why we’re so excited about it.

But first, if you aren’t familiar with Ionic, we make popular open source projects like Ionic Framework and Capacitor, focused on enabling web developers to build award winning mobile apps with their existing web development skills and libraries. Ionic Framework provides a cross-platform UI toolkit focused on the visual aspect of a quality mobile experience, and Capacitor provides a cross-platform runtime and plugin API to access the full native functionality your app needs on each platform it runs on. Use them together or use Capacitor with any web-based UI framework for mobile!

Many developers know Ionic Framework as a mobile toolkit for Angular. And while we fully support Angular today, in the last few years we’ve branched out to supporting React, and now Vue.

It’s no small task for us to officially support a framework. While Ionic Framework’s web components work in any web technology, integration with framework-specific tooling like Routers, CLIs, and more is where the bulk of the work comes, so choosing to support a framework officially is a big deal for us.

Why, then, do we feel it is crucial to support Vue? And why do we feel that Ionic Framework + Vue brings unique value to the ecosystem and an experience that lives up to our goals as a project?

“The best of React and Angular”

Ionic Framework was initially built around AngularJS (that’s the 1.x version) back in 2013. What drew us to AngularJS back then was the ability to incrementally adopt it in any web app, extend HTML with powerful control flow constructs (loops, conditionals, etc), create essentially new HTML tags powered by JS, and easily apply it to any size app from small to enterprise-scale.

While Angular 2 evolved from the original approach taken in AngularJS, doubling down on its focus on large, complex enterprise apps (the kind Google and other large companies build), those original features of AngularJS that drew so many to it in the beginning fell out of favor in exchange for a monolithic solution focused on building large apps from scratch.

When talking to Vue developers, one way they frame why Vue is so great is it essentially perfected that early approach in AngularJS, creating something fundamentally new and compelling along the way. It’s no surprise then that so many Ionic 1.x developers who used AngularJS back then were drawn to Vue when the Angular 2 fork in the road appeared, and picked it up very quickly.

Vue developers often contrast it with React as well, appreciating more powerful data binding (especially with forms), compilation-free templating that uses standard HTML (i.e. no JSX required), and the batteries-included approach where key libraries for routing and state management are officially supported and maintained by the Vue team.

Add these up and it’s clear why many Vue developers consider it to be the best of both worlds.

Vue is exploding

With all the benefits above, it’s no wonder that Vue has found itself a passionate developer base that wasn’t satisfied with the binary Angular or React decision tree and tradeoffs.

That developer base is absolutely exploding, with some metrics, like stars, growing faster than React and nearly any other project on GitHub:

While stars are a vanity metric, there’s proof that this popularity has fostered a strong ecosystem of Vue-specific addons, projects, and frameworks. Vue-specific web app frameworks like Nuxt.js and Gridsome add powerful Jamstack features to the Vue ecosystem. UI libraries like Vuetify, and mobile solutions like Quasar, NativeScript, and Ionic Vue provide options for building engaging UI experiences with Vue across nearly any platform.

It’s clear that Vue is a force to be reckoned with and any web library like Ionic that purports to support the key frameworks web developers are using simply has to take it very seriously.

Ionic Framework and Vue is a perfect match

One of the most common questions we received over the last two years has been “when is Vue support for Ionic Framework coming out?” In fact, we received that question so often that it became a meme inside the company, with us often taking bets on how long it would take for someone to ask about Vue support on any given tweet or blog post (even if it had nothing to do with Vue!)

Obviously, the Vue ecosystem has been hungry for more mobile app development solutions. While a few solutions already exist for building mobile apps with Vue, including NativeScript Vue and Vue Native, what Ionic Framework brings to the table is a mobile development solution that is much more web centric. When you build with Ionic Vue, you’re able to target native iOS and Android with a truly native app that gives you full access to the native device and any native API. At the same time, you get the benefit of a UI layer that is truly web, so any existing web libraries, vue add-ons, UI components, or CSS styles will fit right into your Ionic Vue mobile app. Plus, as a bonus you can deploy your Ionic Vue mobile apps as pure mobile web apps or PWAs.

Ionic is focused intensely on web developers using popular web development technologies, with a massive community, and with support and features for serious apps and enterprise teams. To add on to that, Ionic Framework is backed by a growing company that is focused exclusively on commercializing Ionic Framework and its companion native runtime project, Capacitor.

From a developer experience standpoint, Ionic and Vue have similar roots. Both were inspired by AngularJS to some extent, and both focus on empowering web developers to build incredible things with the technologies they already know, with a low barrier to entry. Vue’s approach of using standard HTML in templates pairs incredibly well with Ionic Framework’s move to Web Components at the core, so using Ionic components feels like any other HTML tag, only with magic mobile powers.

Finally, Ionic is immensely popular, powering nearly 15% of all app stores, and has become synonymous with “mobile for web developers.”

The future is Bright for Vue

The technical challenges and long term maintenance concerns that come with choosing to officially support a framework for Ionic Framework are significant. We will invest considerable resources, financial and otherwise, to support any new framework integration in Ionic Framework.

We have decided to fully embrace and support Vue starting with Vue 3, because we think it is increasingly a pillar of the web development ecosystem, and will only grow in importance and relevance over time.

We also think it spiritually aligns incredibly well with our values and approach with Ionic Framework. We believe in the web platform. We believe in enhancing HTML, CSS, and JavaScript and enabling web developers to do incredible new things with it. Vue helps teams build and orchestrate the functionality and rendering of their app, and Ionic Vue helps those teams make their Vue apps feel great on mobile.

If you’re curious about Ionic Vue and want to try building iOS, Android, and Progressive Web Apps using Vue 3 and all the Vue-compatible web libraries you know and love, take a look at Ionic Vue!

Hey, you there! Want to build a mobile app with Vue but already have a UI library or can't use Ionic Framework's UI controls? Check out Capacitor. It's the native runtime part of the Ionic stack that runs any web app on mobile regardless of what it was built with.

Pullstate - Simple hooks-based state management for React

Max Lynch — Mon, 21 Sep 2020 22:25:53 +0000

State management is one of the most important pieces of an app, and there are a ton of choices for those in the React ecosystem.

In particular, developers building iOS and Android mobile apps with React using Capacitor and Ionic React often ask us for state management recommendations. Of course, there's Redux, which I remain a major fan of, but also much simpler state management approaches like MobX and rolling your own using the Context API.

I've spent a lot of time using Redux and also the bespoke approach with the Context API. Yet, I wasn't satisfied. I wanted to find something that was simple but high performance, and had native integration with Hooks and Function components which I now use exclusively in React (sorry, never want to write the word class ever again 😆).

That's when I stumbled on Pullstate. Pullstate is a small, relatively unknown library (just 300 stars at the time of this writing), but I expect it will become much more popular in time.

Exploring Pullstate

Pullstate provides a simple Store object that is registered globally, and provides hooks for accessing data from that store in a component:

store.ts:

interface StoreType {
  user: User | null;
  currentProject: Project | null;
}

const MyStore = new Store<StoreType>({
 user: null,
 currentProject: null
});

export default MyStore;

Then, in your component, simply use the useState method provided on the store to select data from the store:

const UserProfile: React.FC = () => {
  const user = MyStore.useState(s => s.user);
}

Modifying state

To update state in the store, use the update method:

const setUser = (user: User) => {
  MyStore.update((s, o) => {
    s.user = user;
  });
}

The update function works by mutating a Draft of the state. That draft is then processed to produce a new state.

Usually, a state mutation would raise a red flag, but the magic of Pullstate comes from a really interesting project called Immer. Immer essentially proxies an object and then turns mutations on that object into a new object (in my limited experience with it). Sort of how the vdom does diffing to figure out a new DOM tree.

This is incredibly powerful and simple, but does have a few gotcha's. First, reference comparisons on objects in the s value above will fail, because they are actually Proxy objects. That means doing something like this won't work:

MyStore.update(s => {
  s.project = s.projects.find(p => p === newProject)
});

Instead, use the second argument, o above, which contains the un-proxied original state. Another gotcha is making sure not to return anything from the update function.

Next steps

After having used Pullstate, I will have a hard time not recommending it to all Ionic React developers, and those using Capacitor with other React UI libraries.

I think Pullstate is a great middle ground between being simple for small projects, but clearly capable of scaling to much more complicated projects. For larger projects multiple stores can be created in parallel, for a sort of redux reducer-inspired organization.

Pullstate also comes with some convenience helpers for async actions to cut down on async state boilerplate (such as handling success and failure states), though I have not used those extensively yet.

Next on my list is exploring how this might work with something like reselect for building reusable, memoized selectors.

What do you think? Have you used Pullstate? Please share in the comments!

HIPAA Compliant Mobile Apps With Ionic

Max Lynch — Tue, 18 Aug 2020 14:03:48 +0000

HIPAA compliance for mobile is the responsibility of app development teams and their companies. While mobile technologies and platforms like Ionic provide UI and integration with Native SDKs, they do not handle user data or network security as it pertains to HIPAA compliance. Nor would any other mobile technology, it’s simply out of the purview of a mobile framework.

However, what a platform like Ionic will provide, is the building blocks and APIs needed for teams to correctly implement user data storage and network security to follow HIPAA compliance guidelines and secure Protected Health Information (PHI)

In this post we explore the APIs and techniques often used as part of a HIPAA compliant mobile experience, but discussion of broader HIPAA compliance concerns is out of scope for this blog.

Storing Sensitive User Information

When dealing with sensitive user information, the ideal scenario is to never persist it at all. However, that is not practical for a variety of performance and offline use cases.

Thus, apps must find a way to store user data or sensitive user information, such as authentication tokens encrypted at rest using the full security capabilities of the mobile device.

Consequently, this decision presents two more considerations: securing authentication while enabling biometric auth to enable auto login-in, and storing encrypted data at rest using managed encryption keys.

To enable biometric authentication and the protection and encryption of a user session token, iOS and Android keychain/keystore APIs must be utilized. These APIs enable apps to store sensitive values in secure regions on the device and use powerful encryption that is tangled with the biometric hardware, meaning decryption can only happen with a valid biometric scan. Ultimately, this means data is encrypted at rest and cannot be bypassed on jailbroken devices.

However, there are a number mistakes teams make implementing these complex APIs, and many are documented here.

Thankfully, teams do not have to implement these complex APIs and security flows themselves, as there are off-the-shelf solutions to storing sensitive user data, such as Ionic’s Identity Vault and Encrypted Storage solutions.

Network Transport Security

Apps will need to send data over the network, and this data may contain PHI.

As a start, all network requests must use SSL (aka HTTPS). Ensure every endpoint is protected by SSL. Ensure your app does not embed resources such as images using http://. Also use APIs such as App Transport Security (ATS) to ensure SSL usage across the app.

One other technique your app should strongly consider using is SSL pinning. SSL pinning essentially locks your app into one corresponding valid certificate for a network endpoint. This ensures no man-in-the-middle attack could occur which would result in the compromising of sensitive data.

Protecting Screen Data

When a user suspends an app, most mobile operating systems will show a snapshot of the last state of the app for app switchers and other OS experiences.

To ensure that no sensitive information is leaked in one of these snapshots, your app should listen for app lifecycle events and obscure screen contents. This is typical of most apps in high-security contexts, such as banking.

Accessing Sensitive APIs and Following ToS

Many health apps need to access health data on a device. On iOS, this means HealthKit, on Android, this means Google Fit.

It’s important to make sure any data accessed using these, and other APIs, adheres to your app’s HIPAA requirements.

Additionally, Apple and Google have terms of service requirements for using their APIs. Your app must also follow those.

This point might seem obvious but it’s critical that any access of APIs or sensors is intentional and follows all app store and compliance requirements. Many apps access more data and APIs than they will ever need, creating added security and compliance issues.

Cloud Considerations

Of course, mobile technologies like Ionic focus only on the frontend of an app, rather than the backend. Thus, HIPAA compliance for your app's backend is a separate concern and a massive part of the work in building a HIPAA compliant app.

Likely your backend or infrastructure teams will take this on themselves but it's critical the mobile team works closely with the backend team to ensure no compliance violations occur.

Hit the Ground Running with Ionic

Ionic is a mobile development platform that many healthcare companies are using to build successful HIPAA compliant apps across iOS, Android, and the Web. Ionic offers a number of open source and commercial components focused on enabling developers with a web development background to be highly productive on mobile.

As it pertains to this list of HIPAA compliance needs, Ionic offers some key drop-in security features that make it easy to adopt best practices and meet HIPAA compliance goals.

Ionic Identity Vault brings biometric authentication, along with secure data storage and encryption, using security best practices on iOS and Android. Identity Vault manages using low-level security APIs such as Keychain on iOS and KeyStore on Android, ensuring that sensitive data such as authentication tokens, encryption keys, and sensitive user data are encrypted using the most secure hardware and software capabilities available on each operating system and device. With Identity Vault, apps can support user-expected features such as biometric login without fear of security issues.

Ionic’s Encrypted SQLlite solution provides a high-performance data store with powerful, military-grade encryption support. When used with Identity Vault, encryption keys can be safely managed on device and only available when the actual user is present.

Finally, Ionic’s Auth Connect solution provides a secure authentication flow for popular auth providers (Ping, Azure AD, and more).

Let Ionic Help Make your Mobile Health App Successful

Ionic works with hundreds of enterprise teams building mission-critical, highly secure mobile apps, including many in the healthcare space.

There’s a good chance we can help your team build a successful, highly secure, and compliant mobile health app.

Interested? Get in touch to schedule a demo with an Ionic Solutions Architect.

Saying Goodbye to PhoneGap

Max Lynch — Tue, 11 Aug 2020 15:40:30 +0000

Adobe just announced that they are shuttering PhoneGap, PhoneGap Build, and their (long non-existent) investment in Apache Cordova.

As the pioneer of hybrid app development, aka web developers building mobile apps, this is truly the end of an era.

But it's hardly the end of the hybrid app development story. Companies like Ionic have been the leader in this space for a while, so this sunset feels predictable and, frankly, a long time coming.

I wanted to take this opportunity to reflect on the hybrid app development market, thank the PhoneGap team for pioneering it, and wonder where it goes from here.

Web Devs Rule the World

The brilliant realization that the PhoneGap team had in the beginning was that Web Developers would want to use their existing skills, browser development workflows, and web dev teams to build mobile apps.

Convincing the rest of the mobile market wasn't easy, however. PhoneGap faced intense backlash from the existing native app developer world. These developers went out of their way to trash PhoneGap and the apps that developers were creating on the platform, essentially classifying web developers building mobile apps as second-class. In some cases it felt like a full on war.

Over time, PhoneGap would be proven right: web developers want to use their skills everywhere, and few platforms are as large and as exciting as mobile. Web Developers never stopped honing their mobile skills and the hybrid app development ecosystem evolved to cater to them.

Adobe Passes the Torch

Ionic Framework was launched in 2013 right as the first era of hybrid app development was coming to an end. The iPhone 5 just came out, dramatically pushing the capabilities of the web platform and mobile web performance forward. Android 2.3 was quickly dying and modern Android was just making inroads.

Ionic Framework had a simple pitch: web developers have proven they want to build mobile apps, but there was no official UI library for these apps, so developers struggled to get their UI experience on par with native. Ionic Framework was that library.

Additionally, getting high performance from a web-based UI library was hard, so Ionic took the best practices for web performance and baked them into the UI library so web developers didn't have to worry about it.

And it took off. Over the last 7 years Ionic apps built on Cordova grew to a significant portion of the app stores with millions of apps created.

Along the way, Adobe started taking a back seat and essentially passed the torch to Ionic years ago. Adobe hasn't been active in this space for many years now and Ionic has become the leader in cross-platform mobile app dev for web developers. Thus, the news of PhoneGap shuttering was hardly a surprise.

Web Devs Want to Web Dev

Over the years, the mobile market has changed quite a bit. New projects like React Native, Flutter, and NativeScript have challenged hybrid app development and have brought developers more options for building apps.

But one thing that hasn't changed: web developers want to build web apps and run them everywhere. They want to use their existing skills, browser-based development process, web libraries, and code to build mobile apps. This explained the rise of Cordova/PhoneGap in the first place, and the rise of Electron for desktop.

Cordova (and the modern alternative Capacitor) is still the only game in town for web developers that want to bring their web apps to mobile, and Ionic Framework is still the most popular UI library for them to do it. "Electron for Mobile," if you will.

In contrast, React Native requires developers to build their UI from scratch, won't work with most React web UI projects, doesn't support standard CSS, and can't use most react web libraries (web dev w/ React is 17x more popular than React Native). Flutter requires web devs to throw out their JavaScript investment and their web support is not viable for Progressive Web Apps.

The "build once run anywhere" dream is alive and well in Capacitor and Cordova land, and the many thousands of apps being built on this platform each month as well as significant enterprise traction prove web devs still want to web dev.

What's next?

This space has seen enormous change over the last decade, and it's likely we'll see a lot more in the next. Progressive Web Apps are still nascent but there is growing frustration from developers all over the world about onerous app store requirements that limit a company's ability to reach and serve their users. Many teams are experimenting with Progressive Web App First Development.

Web Developers have honed their ability to build complex apps in the browser and are getting better and better at building high-performance experiences. Thus, the domination of React indicates not that React Native will be the winner for those devs building for mobile, but that React devs building React web apps for mobile is one of the most promising spaces to watch.

Finally, cross-platform is clearly here to stay, and tools like Flutter prove a lot more developers outside of the web dev world want to build for multiple platforms at once. Will it become strange one day to build native apps for single platforms? I don't know, but we're going to find out.

Thanks Adobe

With this news, memories are flooding back of our time working with the PhoneGap team, many of whom have become friends and advisors to us at Ionic. I still find myself dreaming of riding bikes around Amsterdam after PhoneGap Day and the good times we had.

With that, thank you PhoneGap (and, by extension, Adobe) for pioneering this space and helping us at Ionic. Without you, we never would have been able to start this company and we never would have made such great friends.

Farewell 👋

Common Biometric Authentication Security Mistakes

Max Lynch — Tue, 11 Aug 2020 13:34:03 +0000

Most apps utilizing authentication need to provide the user with ways to persist user sessions, or store sensitive values such as encryption keys, all while enabling automatic login using biometrics.

There is one very common way that developers first try to implement this: show the fingerprint or face id prompt, and once the user passes it, load the token or value from local storage or a sqlite database and use it.

Unfortunately, this is the approach that many apps and almost all of the community Cordova/Capacitor plugins take, and it’s not fully secure.

Let’s dig into some common mistakes implementing biometric auth and storing sensitive values, and then learn how proper biometric authentication and secure, encrypted value storage should be implemented.

Mistake #1: Just showing a biometric prompt

The APIs for using biometric hardware on iOS and Android are easy to use at the surface level. Because of this, many developers simply show the biometric dialog (such as a fingerprint or face scan), wait for the success value, and then use that as proof of user presence.

The problem with this is that biometric hardware can be bypassed especially when on a jailbroken device. That means a successful result doesn’t tell you that the real user is actually there. If bypassed, your app may happily load and use sensitive data meant for a different user.

A proper biometric auth flow will protect sensitive data with the actual result of a biometric scan, making it impossible to fake it.

Mistake #2: Not storing tokens and sensitive values encrypted at rest

Many teams store JWT tokens or other sensitive values in unencrypted storage locations, such as Local Storage, an unencrypted SQLite database, or other locations.

Unfortunately, this data can be accessible on jailbroken devices and through other possible exploits, meaning an attacker could find those sensitive values and steal user sessions, encryption keys, or more.

Any sensitive user data or session information needs to be stored using strong encryption.

Mistake #3: Not using Biometric APIs for Keychain/etc.

Teams using Keychain on iOS or Keystore on Android are a few steps ahead, but many are making another big mistake: not using Biometric configuration options for Keychain value storage, or not handling biometric enrollment or revocation so data protected for one user does not become exposed to another user.

This leaves data exposed to exploits and jailbroken devices where the sensitive keychain data could be accessed without a biometric prompt being passed.

Solution: Use Ionic Identity Vault

The low-level security APIs on iOS and Android are complex, but generally, the ability to associate actual biometric data with sensitive values in order to encrypt them in secure locations on the device is the gold standard for mobile security.

That means full usage of the Keychain/KeyStore APIs on iOS/Android, processing biometric enrollment/unenrollment events, using encryption features for databases like SQLite, and making sure sensitive values are combined with biometric data to make them impossible to access without the actual user being present.

Thankfully, teams don’t need to write the complex native code to implement this themselves, as there is a solution to this problem for teams requiring the highest level of security for their apps: Ionic Identity Vault. Identity Vault is a drop-in identity and value storage solution providing advanced biometric APIs for iOS and Android, including deep integration with security APIs and encryption routines.

Identity Vault manages the complexity of biometric authentication, user finger/face enrollment, device-level encryption at rest, and protecting sensitive data on screen.

Additionally, Identity Vault was designed to work with other Ionic enterprise native solutions, including Auth Connect and our encrypted SQLite solution for secure online and offline apps. When used with these solutions, Identity Vault will correctly and securely manage authentication tokens and encryption keys, respectively.

Get Started With Identity Vault Today

Identity Vault is in use at hundreds of enterprise companies and fast growing startups.

We would love to help your team create the most secure mobile app possible with Identity Vault. Interested? Get a demo!

PhoneGap Build Shutting Down? Try Appflow!

Max Lynch — Mon, 10 Aug 2020 15:02:37 +0000

Adobe just announced that PhoneGap and PhoneGap Build are shutting down.

For many teams relying on PhoneGap Build for cross-platform builds, this, along with the recent iOS 13 build issues, is a big setback. Fortunately, it doesn't have to be! There is a great alternative to get your apps working that is a nearly drop-in replacement with some awesome additional features: Appflow from Ionic.

Appflow is a Mobile CI/CD service (aka cloud build service) with native support for hybrid apps, since it’s built by the team behind Ionic Framework and Capacitor. Appflow fully supports PhoneGap, Cordova, and Capacitor apps, and provides managed and secure build environments for iOS, Android, and web. Additionally, Appflow brings remote app updating and direct publishing to app stores, which are significant productivity features that go way beyond PhoneGap Build.

Today, Appflow has thousands of customers and is powering mission-critical apps across the the Fortune 1000 and fast growing startups. Appflow is also being heavily invested in by the Ionic team (read about our recent fundraise), and has a number of exciting features in the pipeline to make native, hybrid, and Progressive Web App development easier and faster (stay tuned!).

We understand that Appflow's pricing model is different from PhoneGap Build. We're currently exploring some pricing and plan changes to better align the two, but for the time being, we are offering new customers one month free when they sign up. Use the coupon BUILDWITHUS when signing up for one month free. Users should start with the Launch plan to explore the native build features. See Pricing for more info.

To get started, explore the detailed migration guide for those switching from PhoneGap Build. We’ve partnered with Adobe to make sure the process is as smooth as possible.

And don't forget: use the coupon BUILDWITHUS when signing up for one month free. Use the Launch plan or above to get access to the cloud app build features in Appflow.

Does your team need help transitioning? Please get in touch, we're standing by to help make this transition as painless as possible.

Finally, we'd like to thank our friends at Adobe and PhoneGap for pioneering hybrid app development as we know it, and hosting some of the best conferences we've ever been to. The time is right for the Ionic team to carry the torch as the modern leader in cross-platform hybrid app development and we are confident we can help any and all teams impacted by this change.

Appflow: not just another CI/CD Service

Max Lynch — Fri, 10 Jul 2020 16:42:49 +0000

Every production mobile app ultimately has a set of recurring tasks around integration, testing, deployment, and long term maintenance. These tasks often must be automated across a team of many developers and app projects. Building a process for these tasks can be incredibly time consuming and require specialized infrastructure experience, but is critical for the success of any serious app project.

Thankfully, teams don’t need to build solutions to these problems themselves, as there are services out there that can help. One such service works directly with your Cordova or Capacitor app to help your team easily perform these tasks. That means consistent builds, deploys on every commit, pushing remote app updates in realtime, and automating app store deployment as part of your mobile CI/CD workflow.

That service is Appflow, and it’s Ionic’s official Mobile DevOps platform. Appflow automates the whole DevOps side of your mobile app project, and is used to power significant apps and development teams across AAA, Burger King/Popeyes, Shipt, and more.

Let’s explore what a Mobile DevOps platform like Appflow is, what Appflow offers, how it differs from traditional CI/CD platforms, and how it’s being used today.

What is Mobile DevOps?

Appflow is known as a Mobile DevOps platform.

Mobile DevOps platforms, of which Appflow is one of the leaders, automate and simplify many continuous integration and delivery tasks, as well as other important mobile app deployment tasks. These platforms handle the heavy lifting so teams can focus on building their unique app, instead of reinventing the wheel.

Those tasks may include:

Setting up consistent, repeatable mobile build environments so apps can be built on every commit using predictable dev tools and operating systems.
Building app binaries and artifacts for iOS, Android, and Web
Running tests and other scripts on every commit to ensure apps stay working
Connecting to existing GitHub, Gitlab, Bitbucket, and other repos to perform builds on every commit
Releasing working updates to users in realtime (for web updates), or to the app stores (for binary updates)
Managing different versions of apps between testers, stakeholders, and production users.

Not every platform supports all of those features (Appflow does, as we’ll see below), but these are generally the tasks that a Capacitor or Cordova development team will need to perform.

Beyond these tasks, DevOps is all about creating a culture of shipping often, involving stakeholders, and ensuring quality. All of which Mobile DevOps products can help your team embrace.

What is Appflow?

Appflow is the official Mobile DevOps platform built by the Ionic team, focused on bringing powerful Mobile DevOps workflows to hybrid app developers across Capacitor and Cordova whether or not they are using Ionic Framework.

Appflow, first and foremost, is a managed mobile build environment. That means it provides consistent and frequently updated iOS, Android, and web build environments. The Appflow team does the hard work of keeping mobile build tools and operating systems up to date and patched for security issues, whether that means updating to the latest versions of Xcode or the Android SDK, or new versions of macOS and Linux, and a whole lot more.

These builds are done in a highly secure environment, so teams can feel confident in offloading their mobile CI/CD process to Appflow, and on high performance hardware to make builds match the speed of development.

Appflow also manages authentic, legal Mac build hardware for fully automating iOS builds in the cloud, which also benefits developers on Windows machines that wish to build iOS apps but can’t or don’t want to buy Mac hardware.

On top of this environment, Appflow provides some pretty transformative features for hybrid app developers. Namely, the ability to remotely update an app without needing to re-submit to app stores (in a way that is App Store ToS friendly!), as well as publish app binaries directly to the Apple App Store and Google Play Store.

And Appflow can automate that whole process so it triggers on each commit, as well as enable powerful version splitting so testers, stakeholders, and customers can run on different versions of an app.

Can’t I do this with Circle CI, GitHub Actions, or Azure DevOps?

In the CI/CD space, there are generic build services like Circle CI or GitHub Actions, and there are specialized services like Appflow.

The biggest difference between the services is that Circle CI or GitHub Actions merely provide build servers, a way to trigger builds, and hooks for sending those builds elsewhere. They do not provide the tools or pipeline for mobile-specific builds, they do not handle the deployment of your app, and they certainly don’t manage build environments for you.

Here’s a visualization of the differences between the two approaches:

In theory, teams could build their own Appflow-style pipeline on another generic CI/CD platform like Circle CI or GitHub Actions, but that would require teams orchestrate and keep up to date a very complex chain of tools, operating systems, build environments, app store submission features, remote app deployment, and more. This is guaranteed to take a full team of engineers with a different skillset than the app dev team to build and manage, especially as new mobile and desktop operating systems are released each year.

It’s simply not feasible for the vast majority of teams to take this on in addition to building their apps.

This is why a specialized build service like Appflow stands out in the CI/CD and DevOps space. Beyond simply being a build service, Appflow is a managed mobile build environment that is fully managed by the mobile experts here at Ionic.

Why not both?

Generic CI/CD tools, with their focus on simply triggering builds, are not a direct replacement for Appflow. That means the two can easily be used alongside each other.

In this scenario, a team might have their generic CI/CD tool trigger builds and push code to Appflow, while Appflow manages the hard work of performing mobile builds on managed mobile development infrastructure, while also handling the last mile app update and app store publishing.

This works so well that around 68% of Appflow customers are using Appflow alongside a general purpose CI/CD tool, according to data from the 2020 Ionic Developer Survey.

This delivers the best of both worlds: You get to continue using your CI/CD tool of choice - or whatever your company has standardized on - while leaving the highly specialized, mobile specific build and publishing requirements to Appflow.

Who’s using Appflow Today?

Appflow has thousands of customers across a diverse range of companies. Appflow powers workflows in fast growing startups, established SMBs, and the largest enterprise companies in the world.

Some of the customers using Appflow as a cornerstone of their mobile app development strategy include RBI (Burger King/Popeyes), AAA, and Shipt. Another customer, Napa Group, had this to say about Appflow:

“One of the huge advantages of using Ionic Appflow was to have these different Channels, which are essentially environments to us. We can push code to our Development environment and have QA test it; then we can move it to Staging and do a smoke test; then, with a single button click [using Ionic Deploy] all our code is live to our users. The amount of risk goes down exponentially compared to deploying the app on the app store, waiting for it to get reviewed, realizing there’s a bug and taking 2 or 3 more days before you can get a fix uploaded. That deployment speed is a huge asset for us.”

See the full Napa Group Case Study for more details on their use of Appflow.

The CI/CD and DevOps market is massive and growing quickly. We believe that every serious app development team will be utilizing CI/CD within the next few years, but most will struggle with sophisticated mobile CI/CD pipelines given their much more complex nature and dependency on a different engineering skillset than app dev teams traditionally have access to.

Thus, teams are choosing Appflow today because they are not able to find what they need from generic CI/CD services like Circle CI, Travis, Azure DevOps, or GitHub Actions. They need reliable build environments and features tailored to hybrid app development. Appflow stands out as the leader in Mobile DevOps and we’re thrilled to see adoption growing quickly as it addresses this huge unmet need.

Getting Started

Getting started with Appflow is easy. Visit useappflow.com, click Try it Free, create or use your existing Ionic account, and jump into the Documentation to see how to connect your app and start pushing commits to Appflow.

Or, if you're interested in exploring Appflow for your team, book a free strategy session with an app architect at Ionic. We help thousands of mobile teams move faster, and we'd love to help yours, too!

Appflow is improving every day. Stay tuned for some really exciting new features coming to Appflow users in the coming months!