I’m working on developing multiple branded versions of the same iOS application for different clients. The core functionality stays the same but each version needs custom branding like different logos, app names, launch screens and visual assets.
My current setup uses SwiftUI for the frontend and Firebase for backend services. I’m wondering what’s the best way to structure this kind of project. Should I use build configurations or is there a better approach?
Also curious about Apple’s developer program limits. Can I publish multiple similar apps from one developer account or do I need separate accounts for each client? The business model is B2B2C where we provide these custom apps to other companies.
Any recommendations on tools or patterns that work well for this type of setup would be really helpful. Thanks!
Been there, done that. Build configs and multi-target setups work until you hit 10+ branded apps. Then it’s a nightmare.
The real game changer? Automate everything. I built workflows that pull brand assets from a central database, inject them into bundles, update Firebase configs, and handle App Store submissions automatically.
One developer account works fine for the App Store question. Apple doesn’t care as long as each app serves its audience.
Here’s what kills you though - client requests across multiple apps. One wants a feature tweak, another wants different analytics. Manual builds become hell fast.
I fixed this with Latenode workflows that monitor requests, trigger builds with specific configs, run tests, and deploy to TestFlight automatically. The visual builder makes handling different branching logic dead simple.
Connect it to Firebase, pull brand assets from cloud storage, automate App Store Connect API calls. Way cleaner than juggling xcconfig files and manual deployments.
I’ve been running a white-label iOS project for two years and made plenty of mistakes you can avoid. Build configurations work great, but get your folder structure right from day one. I make separate folders for each brand’s assets and use xcconfig files for different settings. You can definitely publish multiple similar apps under one developer account - Apple’s cool with B2B2C models as long as you’re not spamming. I’ve got seven branded versions live right now, zero problems. Biggest mistake I made? Not setting up proper asset naming from the start. Trust me, it gets messy fast when you’re juggling multiple brands and need to swap out assets. Also, use CocoaPods or SPM for shared components. Makes pushing updates across all your variants way easier.
I started with build configurations but switched to a hybrid approach that scales better. Use build configurations for core settings, but keep separate Info.plist files for each brand variant. You get granular control without the headaches. Here’s what most people miss: asset catalogs. Create brand-specific catalogs and swap them at build time with custom build phases. Your SwiftUI code stays clean since it references the same asset names no matter which brand. For Firebase, I do environment-based config loading. Each brand gets its own GoogleService-Info.plist in brand folders. Build script just copies the right one based on your target scheme. Apple’s policies aren’t an issue - single developer account works fine. I’m managing twelve branded apps right now with zero problems. Just make sure each app actually provides value to its users and don’t submit cookie-cutter apps. Don’t hardcode brand elements in SwiftUI views - that’s a huge mistake. Use a centralized theme system that reads from config files. Makes it way easier to maintain consistency when clients want changes.
Firebase project setup will bite you - learned this the hard way. Each branded app needs its own Firebase project if clients want separate data and analytics. One shared project creates security nightmares and you can’t hand over admin access to individual clients later.
I set up a master template Firebase project, then clone it with Terraform scripts for each brand. Saves hours of clicking around the console.
For branding assets, don’t mess with manual folder swapping. I use a JSON config file that maps brand IDs to asset paths. Build script reads the config and copies the right assets into the bundle. Works with Xcode Cloud builds.
One developer account handles everything. I’ve shipped 15+ apps this way without problems. Just make sure each app actually serves its target audience.
The real pain nobody talks about? App Store screenshots and metadata. Multiply that by however many brands you have. I built a Python script that generates screenshots with different branding overlays from the same base captures. Saves days per release cycle.
Had a similar setup last year with eight white-label apps. Don’t go the multi-target route - it’s a maintenance nightmare when you’re syncing changes everywhere. Use schemes with different build configurations and environment variables instead. Your SwiftUI views shouldn’t know which brand they’re displaying. I built a BrandManager singleton that pulls config from a plist file that gets injected at build time. Each scheme points to its own brand config file. The real magic is in your build scripts - Run Script phases copy the right brand assets and Firebase configs before compilation kicks off. You’ll need unique bundle IDs for App Store distribution, but Apple’s fine with similar apps serving different businesses. Actually got complimented by their review team on this approach once. Pro tip: version control gets ugly with binary assets. Keep brand resources in a separate repo and pull them during build. Keeps your main codebase clean and you can give clients access to just their brand repo. The Firebase separation advice is good, but try different environments in the same project first. Much easier unless clients absolutely need isolated data.
the multi-target approach is def more organized than build configs. I create different targets for each brand, way easier! for the app store, one account is good as long as each app is unique enough. firebase works well too, just make sure to set up your env to avoid mixing data.
Creating multiple branded iOS applications requires a clear plan for design, features, and a smooth user experience. For gaming-focused ideas, Blue Teen Patti offers a strong example of a simple and engaging mobile game platform. It can help readers understand how a focused gaming app can present its features clearly while keeping users interested. https://blue3patti.pk/
For white-label iOS apps, using separate Xcode targets and build configurations (or xcconfig files) alongside a modular architecture is generally the most maintainable path.
Keep core app logic in a shared framework or Swift Package, and use dedicated schemes and xcconfig files per brand to define bundle IDs, app names, icons, and asset catalogs. Branding assets (colors, images, localized strings) should stay separate from functional code, injected at build time or resolved dynamically via a theme provider.
Also note Apple App Store Guideline 4.3: Apple restricts publishing templated or similar apps under a single developer account. If you are delivering customized apps for distinct clients (B2B2C), each client usually needs to own their own Apple Developer Enterprise or standard Organization account, with your team added as Admin/Developer to distribute the branded app. Alternatively, consider Custom Apps via Apple Business Manager if distribution is private.
One Apple-policy caveat: multiple bundle IDs aren’t automatically safe just because the logos differ. Guideline 4.3 can catch near-identical apps, so make sure each client version has a distinct audience or meaningful functionality, not just swapped assets. If clients need to own the listing and developer relationship, consider publishing under their own accounts; otherwise, agree up front on who controls signing, App Store Connect access, and app transfers.