App development company in San Francisco

A cross-platform app suits products built around accounts, forms, lists, bookings, maps, payments or content. React Native shares most of its code across iOS and Android while rendering each platform’s own interface components. Web developers familiar with JavaScript or TypeScript can contribute, and some logic can also be shared with a React web app. That gives you a common codebase to maintain while retaining platform-specific screens.

Flutter is another cross-platform option. It uses Dart and draws its own interface, which suits a heavily branded product whose screens need to look identical across platforms. Native development in Swift and Kotlin fits apps with deep device features, heavy graphics or complex background work. The trade-off is maintaining separate codebases for iPhone and Android.

A progressive web app can suit a staff tool and avoids store review, though it will not appear in app stores unless packaged for them. On iPhone, it can request notification permission only after being added to the Home Screen. We use React Native for most apps and go native when deep device features make that the better fit.

For a state or local government app, the US accessibility rule requires WCAG 2.1 Level AA. We design the app screens and flows against that standard and build them for the required level of access. Include that work in the scope from the start, alongside the tasks residents need to complete.

Payment setup follows what you sell. We set up in-app purchases and subscriptions for digital features used in the app, and card checkout for physical goods or services used outside it. Stripe is available to businesses signing up in the United States; some storefronts also allow links to outside payment options.

We start with your business, audience and goals, then agree the scope together.

• List the actions users need in the first release, in the order they will do them.
• Note the website, CRM, booking, ERP or payment systems involved, their APIs and who holds admin access.
• Start your company’s Apple and Google developer accounts; organisation verification needs a D-U-N-S number.
• Prepare a privacy policy that matches the data the app collects; Apple requires links in the listing and app.
• List analytics and advertising SDKs so their data collection is covered in Google Play’s Data safety form.

• !

  Wrapping a website in an app shell

  Give people useful app features. Apple’s guidelines ask for more than a repackaged site, and a wrapper risks rejection.

• !

  Demanding sign-up too early

  Let people see useful content or complete a task first where account features are not central to the app.

• !

  Requesting notification permission at launch

  Ask when the benefit is clear, such as after an order. On Android 13 and later, notifications remain off until the user agrees.