I’m working on developing customizable iOS applications for different clients using SwiftUI and Firebase as the backend. The main idea is to keep all the core features the same but allow each client to have their own branding like custom logos, app names, launch screens, and other visual elements.
This is for a business model where we provide these branded apps to other companies who then offer them to their customers. I’m trying to figure out the best way to structure this kind of project.
What approaches have worked well for similar projects? Are there specific design patterns or development tools that make this easier to manage? Also wondering about any potential issues with Apple’s App Store policies when it comes to publishing multiple similar apps from one developer account.
the bundled json approach works well, but xcconfig files are worth considering too. they make managing build settings per client much easier without touching any code. just swap configs at build time and you’re set. saves a lot of headaches later.
totally get the pain of managing builds! config files help a lot, but yeah, apple’s not super forgiving with rejections. i also suggest focusing on unique features for each app, that’s been a game changer for me!
Had to solve this exact problem last year when we rolled out apps for 12 different retail chains.
Here’s what worked: I ditched multiple targets completely. Too much maintenance hell when you scale up.
I built a configuration layer between app launch and the main interface instead. Single codebase, but it reads a bundled JSON file at startup - colors, fonts, feature flags, API endpoints, everything.
The magic happens in your build pipeline. I wrote a script that generates different app bundles from the same source code. Each bundle gets its own config file and assets folder. Takes about 3 minutes to generate all variants.
For SwiftUI theming, create environment objects that cascade down through your view hierarchy. Makes switching themes dead simple and keeps your views clean.
App Store wise - yeah, they’ll flag you if apps are too similar. But I found a workaround. Make sure each client app has at least one genuinely different feature or content area. Even something small like different onboarding flows or unique integrations works.
Also, push hard for clients to use their own developer accounts. Saves you from rejection headaches and they can manage their own app store presence. Win-win.
Been there! Had a SaaS that needed white-label mobile apps and it was a nightmare until I figured out the right approach. I built one core app that pulls everything dynamically - branding, config data, the works. Used Firebase remote config for this. Way better than juggling multiple codebases. For the build process, I set up Xcode schemes for each client. Each scheme handles the basics during compile (bundle ID, app name, core branding). Everything else gets pulled from remote config, which is huge because you can update branding without waiting for App Store approval. Word of warning on App Store stuff - Apple will reject apps that look too similar. I got burned on three submissions for being “spam-like.” Make sure each app actually serves different users and has some unique functionality beyond just different colors/logos. Keep documentation showing you have real client relationships too. Helps with reviews.
I’ve built a few white-label solutions and learned some hard lessons. Skip remote configs for everything - use local configuration files instead. Set up separate Xcode targets with their own Info.plist files and asset catalogs. Way cleaner for App Store submissions since each bundle is actually different. Build your theming system early or you’ll hate yourself later. I made a Theme manager that pulls from local configs and handles all the branding across SwiftUI views. Beats having styling hardcoded everywhere. For App Store approval, make sure each client app actually serves different users or markets. Apple’s cool with it when apps target different regions or industries. Keep good records of your client relationships and push them to submit under their own developer accounts if you can. Keeps your main account safe from spam flags.