In one of our recent projects, we didn't have time to set up different project
phases as completion basically required an approach of "repaint the car, then
gut the interior and replace the engine" to get it to a shippable state and
keep management happy.
Now that this is complete and ready to deploy, we are slowly moving in phases
into the project and certain gatekeeper approaches as this is a data driven
application and we don't want to push changes to the live version that craters
our thousands (wishfully) of users across the world.
Now that we have declared a Live version and we are modifying external HTTP
data in a Staging version, I recommended that we take this approach:
In an internal pList, add a bool that is the staging property. By default, if
it's false, the app will be live and point to the live data root URL.
Use a badge on the icon for the app that shows that it's not the live version,
but the staging one. (I have source AI, PS and PNG files for a Staging badge
for a 57 x 57 icon if anyone wants)
It is expected that people will have two versions of the app on their iOS
devices, but this approach means that If we rebuild the same app with the flag
set to Staging and install it OTA, this will replace the previous app, which we
don't want.
Otherwise, we'd have to keep two codebases up to date, which is a bad idea.
Would programmatically altering the Bundle Identifier of the app to add in the
state of the staging property allow two builds to exist on the same device from
the same codebase?
So, instead of using this as a bundle,
com.thisBigCompany.${PRODUCT_NAME:rfc1034identifier}
We would have something like com.thisBigCompany.thatApp0 or
com.thisBigCompany.thatApp1.
Or would this need to be done in the Bundle, not the Bundle Identifier?
In any case, let me know if this is a stupid idea, or seems to be on track.
TIA.
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
