Question 1

Should my app be native or cross-platform?

Accepted Answer

For most products that need both iOS and Android, cross-platform with React Native or Flutter is the better use of budget: one codebase, one team, and native code only where it’s needed. I recommend fully native Swift and Kotlin when the app depends heavily on platform features (widgets, watch apps, CarPlay, complex Bluetooth or background work), when one platform dominates your audience, or when you already have separate native teams. Kotlin Multiplatform is a middle path: shared business logic with native UI on each side.

Question 2

React Native or Flutter — which do you recommend?

Accepted Answer

Both are mature and either can produce a good app. React Native suits teams that already work in TypeScript and React, and it renders real platform UI components. Flutter draws its own UI, which makes pixel-identical custom designs easier and keeps behaviour consistent across devices, at the cost of reproducing platform conventions deliberately. I weigh your team’s skills, the design, the native SDKs you depend on and who will maintain the app afterwards, and I write the reasoning down so it can be revisited.

Question 3

Do you use Expo, and does it limit what the app can do?

Accepted Answer

For new React Native apps, usually yes. The idea that Expo rules out custom native code is out of date: with development builds, config plugins and Expo Modules you can add any native library or write your own Swift and Kotlin. I use Continuous Native Generation (prebuild) when the native projects can be generated from configuration, and keep the native folders checked in when an app needs heavy manual native changes. EAS is optional; the same app can build on your own CI.

Question 4

When is Ionic with Capacitor the right choice?

Accepted Answer

When you already have a well-built web app, your team works in Angular, React or Vue, and the app is mostly forms, lists, content and standard device features such as camera, push and location. You reuse most of the web code and still ship to both stores. It’s a weaker fit for heavy animation, very long lists on low-end Android phones or deep background work, because the UI runs in a web view. If your roadmap is likely to outgrow it, I’ll say so before you start.

Question 5

Can you take over an app that another developer or agency built?

Accepted Answer

Yes. I start with a short audit: whether it builds on current Xcode and Android tooling, which dependencies are outdated or abandoned, what the crash data says, how signing and store access are set up, and where the risky code is. You get a written summary and a prioritized plan. Most inherited apps can be stabilized and modernized step by step; I only suggest a rewrite when the audit shows that incremental work would cost more.

Question 6

Will the app work without an internet connection?

Accepted Answer

It can, but offline support has to be designed in. Offline-first apps keep data in a local database, queue changes in an outbox and sync when connectivity returns. The hard part is deciding what happens when two people change the same record while offline, so I agree conflict rules with you for each type of data before building. Adding offline support to an app built around live API calls is possible, but it usually means reworking the data layer.

Question 7

Do I have to use Apple’s and Google’s in-app purchase systems?

Accepted Answer

It depends on what you sell. Digital content, subscriptions and premium features used inside the app generally have to use In-App Purchase on iOS and Google Play Billing on Android. Physical goods and services used outside the app — products, food, rides, appointments — use a normal payment provider such as Stripe, with Apple Pay and Google Pay. The rules on linking to outside payment pages vary by country and have changed recently in the US and the EU, so I check the current policies for your launch markets before designing checkout.

Question 8

Who owns the code, the developer accounts and the signing keys?

Accepted Answer

You do. The apps should live in your own Apple Developer and Google Play accounts, with me invited as a team member, and the code goes into your repository from day one. Signing certificates, the Android upload key and API keys are stored in your accounts or secrets manager and documented. Android apps use Play App Signing, so a lost upload key can be reset instead of ending your ability to update the app.

Question 9

How long does App Store and Google Play review take?

Accepted Answer

Apple reviews most submissions within a day or two, though first submissions and apps with sensitive features can take longer or come back with questions. Google Play reviews of updates are often quick, but new apps can take several days, and new personal developer accounts must complete a closed test with a minimum number of testers before getting production access. I build that time into the plan and prepare review notes, demo accounts and privacy disclosures in advance, which prevents the most common rejections.

Question 10

How do you keep the app and its users’ data secure?

Accepted Answer

Secrets stay on the server, and the API — not the app — decides who can do what. On the device, tokens and keys go into the iOS Keychain or Android Keystore-backed storage, sign-in uses OAuth 2.0 with PKCE in the system browser, and biometric unlock is tied to hardware-protected keys. I review the app against OWASP MASVS, decide with you whether certificate pinning is worth its operational risk, and keep personal data out of logs, analytics and push payloads.

Question 11

Can you ship fixes without waiting for app review?

Accepted Answer

Partly. React Native and Expo apps can receive JavaScript and asset updates over the air through EAS Update, which is useful for urgent bug fixes. Those updates can’t change native code, and the store terms don’t allow them to change the app’s purpose or add features that differ from what was reviewed. Native apps need a store release for code changes, Flutter code-push exists only through third-party services with their own trade-offs, and every stack can use remote configuration and feature flags to switch already-shipped behaviour on or off.

Question 12

What happens after launch?

Accepted Answer

The work changes rather than stops. Every year brings new iOS and Android versions, a new Google Play target-API deadline, Xcode changes and SDK deprecations. Ongoing maintenance covers crash and vitals monitoring, dependency upgrades, testing on OS betas before release, and improvements based on how people actually use the app. If you’d rather take the app in-house, I document the architecture, build and release process so a new team can pick it up.