This month Mindgrub and Wheelhouse Analytics released Salesbag 1.0, a sales presentation tool geared at the financial services industry. The project represents somewhat of departure for Mindgrub as a consultancy. Most previous projects have been a once-and-done kind of project. For Salesbag we’ll be working long-term with Wheelhouse to release frequent updates to the app.
This presented numerous challenges as 1.0 got out the door and we started work on the first set of updates. Aside from our internal testing team, Wheelhouse has a team of their own. They want to be able to show the app store version off while still testing our updated builds to them. To keep the development and live builds totally separate we decided the best course was to create separate target for the dev version that they would use for their testing. To iPad, these would look like entirely different apps, so we’d never run the chance of damaging the live data during testing. In the rest of this post I’ll detail how to create a separate development target for testing purposes some of the added benefits you’ll get out of doing this.
Step 1 – Create a new app id and provisioning profile.
In the provisioning portal, create a new app id and ad hoc provisioning portal. I assume that everyone reading knows how to do this. For Salesbag we created a com.wheelhouse.salesbagDev app id.
Step 2 – Create a duplicate target
Duplicating the target is simple. Simply right click the build target in the project details and select “duplicate”.
Step 3 – Create a duplicate info plist
In order to use the new app id, we’ll need to duplicate and modify the info.plist to include the new app id.
You can also change other build settings like the bundle display name to make your dev version distinguishable from the production app.
Step 4 – Modify the target build settings to include the new plist
The new target must know to use the new the info.plist. Open the build settings for the target, search for info, and change the name of the info.plist.
Step 5 – Create a new scheme to build the new target
The last thing to do is to create a new scheme to build the new target. Under the schemes drop down at the top of the Xcode window and select manage schemes to bring up the scheme manager. You select duplicate from the actions (gear) menu at the bottom of the window.
Once your new scheme is created, click edit to open the new scheme. All you need to do next is replace the old target with your dev target and hit ok (this is in the “build” section).
You should now see the new scheme in the schemes drop down.
BONUS – Setup target specific code
In the dev version of salesbag we added some features for testers to be able to wipe out old data from previous iterations of Salesbag (in our case local eventkit calendars from development on the earlier versions). With your new target you can easily create custom preprocessor directives to dynamically include code in dev versions that you give to your testers.
Step 1 – Create a new preprocessor macro
In the build settings for the dev target search for preprocessor and double click the section called Preprocessor Macros under the target. Add a new parameter in here. We chose “DEV_VERSION=1″.
Step 2 – Use your new macro in code
To include code specifically for your dev version, simply use the macro you created in step 1:
#if DEV_VERSION NSLog(@"cool testing feature"); #endif
Hopefully the process above will help some other developers in their longer term projects. Also be sure to drop a comment if you have any feedback. Happy coding!
I don’t know how it is I haven’t come across this stackoverflow discussion about iPhone app costs before.
Like most developers, I’m asked frequently to run levels of estimate for software projects at work and in the freelance arena. Consistently, I feel like there’s pressure to give the client a number that they can swallow, which is ordinarily way under what the work is at a quality level I’m comfortable with. It’s a constant battle for me to be honest with myself about the time required to actually complete the work. After all, everyone loves to get the contract.
Of course, the downside is, and everyone knows it, that a gross under-bid is bad for everyone. As the developer, you feel overly constrained to meet unrealistic deadlines, you wind up putting in hours for free or feel like you’re not serving your clients as well as you can by delivering a sub-par product.
The discussion is an excellent read for folks who always find themselves having to place numbers on iOS projects. It’s refreshing to get a peek into the scales of production from the developers of some the most revered apps out there.