Shipping the Same App on iOS and Android: What Actually Changes

If you have only built an app for one platform, it is easy to think that supporting both iPhone and Android simply means adjusting the design for two different screen sizes.

That is not the case when your app deals with things like app permissions, screen time, usage tracking, app blocking, or running in the background. Once you build these types of features, iOS and Android start to look less like two versions of the same platform and more like two completely different systems.

The biggest differences are below.

1. Permissions: one simple approval vs. several steps

On iPhone, many screen-time features are controlled through Apple's Family Controls system. The user generally gives your app one important permission, and that permission unlocks the features your app needs. If the user denies it, they may need to go into Settings to change their decision.

Android works differently. An app that wants similar capabilities may need several separate permissions, such as:

• Permission to see how much time is being spent in other apps
• Permission to detect when another app is being opened
• Permission to send notifications
• Additional battery or background permissions on some phone manufacturers
• In some cases, extra permissions if the app needs stronger protection against being removed

This creates a very different onboarding experience. On iPhone it can feel like "allow this permission → you're ready." On Android it can feel more like "open Settings → enable this → go somewhere else → enable another permission → adjust battery settings → come back." And if even one permission is missing, one part of the app may stop working.

2. You cannot get a list of apps the same way

Android gives apps much more freedom to see which apps are installed on the phone. A wellbeing app can usually build its own list of installed apps and show them to the user: search that list, display app names and icons, and remember which apps the user selected.

iPhone does not work this way. Apple does not allow a third-party app to simply look at everything installed on the phone. Instead, Apple provides its own app-selection screen, and the user chooses the apps they want to manage through Apple's interface.

This means the product experience has to be different: on Android you can build your own searchable app catalogue, on iPhone you have to work within Apple's selection system.

3. An app does not have the same identity on both platforms

On Android, an app has a package name that can be used to identify it, so saving something like "block Instagram" is relatively straightforward.

iPhone uses a different system. The apps selected through Apple's Family Controls system are represented by special tokens rather than normal app identifiers, and those tokens are connected to the user's iCloud identity.

That matters when your app has its own user accounts. Imagine two people sign into your app using different accounts on the same iPhone. If you store their selected apps together without separating the data, one person's settings could accidentally affect the other person's. So on iPhone, app selections need to be carefully connected to your own user account. This is not simply a technical detail, it becomes an important part of the product's data design.

4. Blocking an app works very differently

This is one of the biggest differences between the platforms.

On iPhone, Apple provides a system-level way to place a shield over an app. When an app is blocked, the user does not open it and then get kicked out, Apple's system prevents the app from being used in the first place. That makes the experience feel natural and reliable.

Android does not provide an equivalent public system for third-party apps. A common approach is to monitor which app is currently being opened; if the user opens an app that should be blocked, your app detects it and sends the user back to the previous screen or home screen. In simple terms:

5. Usage history exists on Android, but not the same way on iPhone

Suppose your product promises: "See how much time you spent on Instagram last week."

Android can generally provide historical usage information through its built-in usage tracking system. A new user may be able to see usage from before your app was installed, as long as the phone still has that information.

iPhone is different. Your app does not get direct access to Apple's existing Screen Time history. Instead, your app has to start collecting information through Apple's supported reporting system, so the data effectively starts from the point at which your app begins tracking.

If a user installs your app today and asks "how much time did I spend on Instagram last Tuesday?", you cannot read that from Apple's Screen Time database. If your product promises historical usage immediately after installation, Android can support that much more naturally than iPhone, and you should not pretend otherwise.

6. Background work: consistent on iPhone, flexible but unpredictable on Android

Many wellbeing apps need to keep working when the user is not in the app, say a schedule like "block social media every weekday from 9 AM to 5 PM."

On iPhone, Apple provides a background system designed for exactly this, and it can keep enforcing the rules even after the main app is closed. The trade-off is strict limits: scheduling restrictions, timing limitations, and situations where the system may not respond at the exact moment you expect. For extremely precise timing, developers may need backup mechanisms.

Android gives developers more flexibility, background services, scheduled tasks, alarms. But some Android manufacturers aggressively stop apps from running in the background to save battery. Phones from manufacturers such as Xiaomi, Oppo and Vivo can require users to manually allow background activity or enable automatic startup.

So the two platforms have opposite problems: iPhone is strict but relatively consistent; Android is flexible but the phone manufacturer can interfere.

7. Different parts of an iPhone app need to share information

On iPhone, these wellbeing features are often split into several parts: the main app, a monitoring component, a component that controls what the blocked screen looks like, and one that generates usage reports. These parts need a shared place to store information, and Apple provides App Groups for this purpose.

This is another area where iPhone development requires more planning, if the parts are not using the same shared storage correctly, one part may not know what another has changed. Android is generally simpler here because many of these features can operate within the same app and background service, but it introduces more uncertainty around manufacturers and background restrictions.

8. Supporting an older phone is not just about whether an API exists

iPhone has a clear minimum version for many of these capabilities: the Family Controls, Device Activity and Managed Settings technologies used for individual screen-time management require relatively recent versions of iOS.

Android has supported usage tracking and accessibility capabilities for much longer, but just because Android technically supports something does not mean every Android phone behaves the same way. Different manufacturers change settings, menus, battery restrictions and background behavior. Testing on one Android phone is not enough.

9. Uninstall protection is different too

Some wellbeing apps want to prevent users from simply uninstalling the app when they are trying to avoid distractions.

iPhone provides a setting that can prevent apps from being removed, but it is a device-level control, not a per-app feature that says "protect only my app." Using it as straightforward uninstall protection can create the wrong product experience.

Android has stronger options in some scenarios, including device administration features. However, these permissions are powerful and can create a serious, sometimes intimidating user experience, and they need to be justified from both a product and policy perspective.

10. What can be shared between iOS and Android?

A shared app framework, such as React Native, can handle many parts of the product: user accounts, login and sessions, general app screens, schedules, settings, business logic, and much of the user interface. But the platform-specific parts still need to be built differently:

This is why simply copying the same product design from one platform to the other usually does not work well.

The takeaway

iPhone and Android are not just two different screens for the same product. They have different rules for permissions, app selection, app blocking, usage history, background activity and data sharing.

iPhone is more controlled by Apple: the system does much of the enforcement for you, but you have to work within Apple's rules. Android gives you more freedom to access apps and usage information, but you also have to deal with more permissions and manufacturers that may interfere with background activity.

So when you build the same wellbeing product for both platforms, the real work is not copying the screens. The real work is understanding that "block this app," "show this week's usage," and "make sure this still works tomorrow morning" are different problems on iPhone and Android.