Adding Core Data to an already existing XCode4 project

1. The mechanism to add the model is simple:
   

   Ctrl+Click > New File > Core Data > Data Model > Next > Save

   but this only works if you Ctrl+Click on the project!
   
   • If you Ctrl+Click anywhere else, for example lets say on the Resources folder, then you will get a useless .xcdatamodeld file which simply won't open in the editor.
   • So make sure to add the model file by Ctrl+Click(ing) on the project name and nothing else.
   • Beware, if try to move it to an appropriate location like Resources at a later time, it will stop working again. After the move, once again, no editor will come up if your try to re-select the .xcdatamodeld file.
   • You must have it directly under the project in order to be able to work with it.

Versioning iPhone App: Beta & Production Builds

A little bit of Google search yields the following great resources to help get started in the arena of versioning your iOS apps:

• easy-iphone-application-versioning-with-agvtool
• recipe-automatic-version-number-build-number-build-date-handling
• setting-ios-application-build-versions

In this blog entry, I'll:

• attempt to provide the grand total of everything I learned from these articles which are based in XCode3,
• provide instructions on how to do the same in XCode4, and
• explain some of the finer points which weren't clear to me without trial & error.

1. This snapshot shows how to add apple generic versioning to your XCode4 project.

2. Open YOUR_PROJECT in XCode 4 and navigate to YOUR_PROJECT > Targets > YOUR_PROJECT > Summary > iOS Application Target > Version
   
3. Even though it may seem intuitive to think so but this is NOT the version number that the iPhone app users will see.
4. Instead this is an internal build number that you can increment as many times as you like and whenever you deem appropriate. Follow the links at the top to learn more.

5. You can easily comfirm this by attempting to edit this property in YOUR_PROJECT > Target > YOUR_PROJECT > Info (maps to YOUR_PROJECT-Info.plist file) > Custom iOS Target Properties > Bundle Version
   and then confirming that the change took effect again in Summary > iOS Application Target > Version
   

6. If you Ctrl+click and ask it to Show raw keys/values

7. Then you'll notice that this maps to the key: CFBundleVersion
8. If you would eventually like to build your "About" page in the app and format a string that shows up something like version 0.1.0 (build 42), where 42 will correspond to the value of CFBundleVersion, then instead of giving it an initial value like 1.0, I would suggest setting it to 1

9. So now what corresponds to the 0.1.0 part of the version 0.1.0 (build 42) in your about page? Well, the Bundle versions string, short property with the raw key value of CFBundleShortVersionString would make up the 0.1.0 piece of that string.

10. And could this 0.1.0 be the version # that is displayed as your app's version in the App Store? Yes! this is known as the marketing version and it is what shows up to the users of the App Store.
11. What's up with the x.y.z version structure? As one of the links in the beginning explains, X - major revision number, Y - minor revision number, Z - maintenance or patch release. This is a very nice & simple concept to use.
12. Why should the starting of an App's marketing version be from 0.1.0? Because an application would like to enter the App Store as 1.0.0, so you don't want to use 1 as your major (X) version in the very beginning when you are probably in the process of distributing Ad-Hoc builds for alpha/beta testing. 1 as your minor (Y) version makes sense 0.1.0 because your app starts with the smallest set of features and then grows to perhaps 0.2.0, 0.3.0 and so on. Also the 0 as your patch (Z) version makes sense because there is nothing for you to patch at the very start. In conclusion: minor.major.patch is conveniently 0.1.0 for starters.
13. Here's what my email notification message looks like when I use TestFlightApp to publish beta builds to testers: v0.1.0 (4) of ShoppinPal is ready for a TestFlight
14. To check your CFBundleVersion via Terminal, use:

    agvtool what-version

15. All the following commands increment CFBundleVersion by 1 but do nothing to CFBundleShortVersionString:

    agvtool next-version
    agvtool next-version -all
    agvtool bump -all

16. To check your CFBundleShortVersionString via Terminal, use:

    agvtool what-marketing-version

17. To change CFBundleShortVersionString, you will yourself have to understand if the change is major, minor or patch and then use:
    

    agvtool new-marketing-version 0.2.0

18. With XCode4 there really shouldn't be any good reason not to use Git so remember to commit to the repository every time after you change the version. Perhaps even take the time to tag the repo so that you can pull the exact source for debugging if someone ever reports an issue against a specific version/build #

PayPal: Why their mobile integration grinds my gears

Sometimes it is frustrating to see a company or business excel at something and then be so bad at advertising it! PayPal's mobile integration makes that list because it doesn't show up in the first page of google search results.

Why would you have something so awesome but fail to show-up when people search for you? Perhaps they are protected against search engine crawlers? Anyway, allow me to break it down for you the reader, who found this blog through a google search ... and let you know what I think is the best way to get up and running with the PayPal iPhone in-app payment awesomeness:

1. The 1st 4 slides are enough to put a smile on any face: Mobile Express Checkout - best practices
   
2. Here's the landing pad for mobile devs. Let me make it even simpler, get this reading material in the following order:
1. Mobile Payments Library Developer Guide and Reference – iOS Edition
2. Sandbox User Guide
3. PayPal Express Checkout Integration Guide
3. Only importing the PayPal header files and libPayPalMEP.a is not enough. There are a few indirect dependencies too, you can figure out what they are by looking at the configuration for the Simple and Interactive demos ... so make sure to add them to your project as well:
   • libz.dylib
   • libxml2.dylib
   • Security.framework
4. You will probably have no trouble with the simple integration but as your business model and transactions become more & more complex, you'll run into error codes which will be hard to make heads or tails of. At that time sign-in to your PayPal developer account and refer to
   DOC-1412 for the meaning behind the cryptic codes.
   • One example of such a cryptic code is 589023, which maps to: "If a fractional amount is rounded due to currency conversion, funds could be lost"
   • Now this is confusing on a whole different level because there may not be any currency conversion involved in the transaction at all! So the error might seem to make no sense at all BUT it turns out that PayPal just wants your app to submit NSDecimalNumbers that do not have more than 2 decimal places. I didn't understand this simple requirement until I came across this post. Luckily, this blog makes it clearer on how to apply such a policy when you have made a decision.

Happy coding!