App phases + appropriate phase icon badges.
App phases + appropriate phase icon badges.
- Subject: App phases + appropriate phase icon badges.
- From: Alex Zavatone <email@hidden>
- Date: Wed, 29 Aug 2012 12:05:51 -0400
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@hidden)
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:
This email sent to email@hidden