I need to distribute the same iOS application to several different customers, each with their own branding, app name, and icons. The application includes push notification functionality using a backend service. I’m trying to understand the complete workflow for creating these branded variants from a single codebase.
From what I can gather, this process might include:
- Setting up separate Bundle IDs for each branded version
- Generating individual provisioning profiles for development and distribution
- Building separate Xcode targets for each customer variant
- Configuring different backend service instances for each brand
- Managing unique API credentials per target
- Publishing each variant as a separate App Store listing
- Handling marketing materials and store assets for each version
- Maintaining updates across all branded applications
Is there a more streamlined approach to manage multiple white-labeled iOS apps, or are all these steps necessary for proper distribution?
Been through this exact scenario multiple times at my company. You’re mostly on the right track, but there are some shortcuts you can take.
The Bundle ID and provisioning profile dance is unavoidable - Apple forces this on you. But here’s what I learned: use Xcode’s build configurations instead of separate targets. Create a config file for each brand with all the variables (app name, colors, API keys, etc). Way cleaner than maintaining multiple targets.
For push notifications, don’t set up separate backend instances unless you absolutely need isolation. One backend can handle multiple apps if you include the Bundle ID in your payload routing. Saves you tons of infrastructure headaches.
The real pain point nobody talks about is certificate management. I use Fastlane match to handle all the signing certificates automatically. Stores everything in a private git repo and handles renewals. Game changer.
App Store submissions are still manual work unfortunately. Each brand needs its own developer account ideally, or at least separate app listings. Screenshots and metadata have to be unique too.
One trick: use environment variables in your build process to swap out assets and config files automatically. Makes builds way less error prone than manually switching files around.
Having built multiple white-labeled iOS apps, I can confirm that most of the steps you’ve outlined are indeed necessary due to Apple’s requirements for unique Bundle IDs. However, there’s a more efficient method to streamline the process. Instead of creating separate targets in Xcode, consider using schemes with build configurations. This allows you to manage different app parameters—like names, Bundle IDs, and even API endpoints—from a single codebase through configuration files. Although you still need individual provisioning profiles, Xcode’s automated signing simplifies this aspect. For handling push notifications, utilizing a service like Firebase can help manage multiple app certificates efficiently. The biggest challenge typically lies in App Store submissions, as each brand will require distinct metadata and screenshots, alongside separate review processes.
I’ve done this exact setup for three client projects, and yeah, your workflow is spot on. There’s no magic bullet here - Apple’s ecosystem forces you to create separate Bundle IDs and certificates for each app variant. The push notifications were the biggest pain. Each Bundle ID needs its own APNs certificate, so you’re managing multiple .p12 files and tracking expiration dates. I switched to APNs authentication keys instead - they work across all apps under your developer account and don’t expire as often. For the backend, don’t spin up separate service instances. I built a tenant-based system where one backend handles multiple brands but routes notifications based on app identifiers. Cut infrastructure costs way down while keeping everything properly separated. One thing you missed: testing becomes a nightmare. You need separate TestFlight builds for each brand, which means coordinating beta testing across multiple app listings. Plus Apple treats each variant as a completely different app during review, so that process gets messy fast.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.