daCapo Blog

Useful Objective C Book

dacapo — Thu, 03 Nov 2011 04:18:00 +0000

Some development books get outdated real fast due to the rapid pace of changes in the iOS SDK. Because of that, I find it hard to recommend books to new iOS developers. But here is one resource that is very useful to have.

The book is quite thorough and covers most of the basics that can help with programming in Objective C. Highly recommended!

Of course, the more impatient types will likely opt for something like Beginning iPhone 4 Development: Exploring the iOS SDK by LaMarche, et al. I’d recommend this as well for getting through the initial hurdles and actually getting an app developed in the shortest time possible. However, these types of SDK-specific books get outdated rather quickly, since, as we all know, it’s no longer about iOS4 but rather iOS 5 nowadays.

If you want to get up and running ASAP, you’ll do well with the iPhone development book by LaMarche and others. But if you want the fundamentals, go for the Objective C book. But if you are just starting out, my best recommendation is to get both books.

Will your app be rejected?

dacapo — Fri, 14 Oct 2011 00:11:38 +0000

For the consumer, the iTunes App Store is better than the Android marketplace because it is a “curated” market, which means that there are people who actually review apps to make sure that they are acceptable for publishing.

Now, this is a double-edged sword, because on the one hand, it should ensure a certain minimal level of functionality. But in reality, it is an imperfect process and is also an evolving set of guidelines. (Translation: moving target!)

In the past few months, since around the time of WWDC 2011, the App Reviewers seem to have gotten much more stringent.

I’ve done a lot of development work for clients, and here are two of the most common reasons for rejection that I’ve seen. So, before starting a project, I usually advise them of the possibility that their app may be rejected.

RSS Feed Readers

A lot of people assume that they can simply take their website or blog and create an iOS app and instantly reap the benefits of an additional target market. While this may have been true in the earlier years, it definitely is no longer true. For the most part, standalone RSS feed readers will be rejected. There are always innovative ways to work around these rejections, but it can really rattle you to the core to get an email that says something like, “(Name of your app): App Submission Feedback” instead of the typical “Your app status is Processing for the App Store.”

The good news, however, is that it’s not impossible to get even your personal blog on the App Store. The actual solution may be slightly different depending on the app type, but typically the solution involves providing some sort of functionality that only an app can provide and something that a mobile optimized website can’t provide. (I’ve done so successfully myself for a couple of clients, so I know for sure that it can be done. Obviously, this is something that I can divulge only to clients.)

Brochure-Ware

Another common reason for rejection is also related to porting website content or their marketing collateral into an iOS app. This is a common pitfall, because a lot of small to medium sized companies register for an Apple Developer account just to gain a presence on the App Store. While this seems to be more of a hit-or-miss situation than RSS feed apps (which seem to be nearly 100% rejections), it may be better to add other features that take advantage of iOS device capabilities ahead of time.

Do you see a pattern? The App Store is trying hard to differentiate itself from the web by ensuring that the apps are not just websites in a new skin. This doesn’t mean, however, that you should forget about publishing an app altogether if you have a blog that you want to turn into an app.

Just as the saying goes, there really is more than one way to skin a cat. There are many ways of adding in specific features so that an app can pass the review process. Hopefully your development provider is experienced enough to help you navigate the waters. It can’t hurt to ask any potential providers upfront if they have any knowledge about whether or not your app idea might get rejected.

“SEO Optimizing” Your App for iTunes – Part 4 (Additional Findings)

dacapo — Wed, 12 Oct 2011 18:02:50 +0000

In my continuing quest to SEO optimize my apps for iTunes, I’ve just made what I think is a very important discovery, the hard way.

For one of my apps, I had a phrase, like the following:
AAA, BBB CCC, DDD
where AAA, BBB, CCC, DDD are individual keywords.

But the strangest thing was that my app simply wouldn’t come up in iTunes when I did a search for BBB CCC. I found that very odd that some of my keywords were apparently not being indexed, so I shot off an email to the support. After getting several rounds of standard cut/paste responses, I finally get a phone call (that I missed) and an email, which explained to me what happened.

Apparently, what happened was that the App Reviewer actually rejected my BBB CCC phrase, because they found that it matched the name of another app! The rejection is done manually, but the scary thing is that there is nothing in iTunes Connect that alerts you of this!

So, you could go on happily thinking that you’re SEO-optimized completely oblivious of the fact that some of your keywords may have been removed from indexing. That is a really scary thought.

Had I used BBB,CCC instead, it would have indexed properly. The email from Apple went so far as to suggest that using individual keywords would have gotten my app indexed properly.

So, two very important findings from an SEO optimization perspective.

1. When using keywords, be careful that your keywords won’t be flagged for being the same as another live app on the store. I would imagine this doesn’t happen in general for single keywords, but can happen for phrases. This can happen completely without your knowledge. It may not always happen since it’s evidently a manual flagging process, but you don’t want to take chances.

2. Instead, use single keywords separated by commas rather than by using spaces, to prevent an app reviewer from inadvertently mistaking your keyword phrase for an app name and inappropriately flag it to exclude it from the indexing process.

Hope this helps!

How to take easy screenshots from iPhone Simulator

dacapo — Tue, 11 Oct 2011 19:22:29 +0000

Capturing screenshots of your app for iTunes Connect can feel like a laborious process. For clients that don’t have a Mac, I have to advise them to take manual screenshots on their device using the sleep and home button combination and then to email it to themselves. However, this is really slow, and should be done only if you do not have a Mac.

If you do have a Mac and you’ve installed XCode, then it’s relatively painless to do screen captures. And no, I don’t advise buying an app or some other method to do this.

1. Launch XCode and open up your XCode project file.
2. Build and run your app on the iPhone Simulator (or the iPad Simulator).
3. Simply press Cmd+Ctrl+C.
4. Launch the Preview app, and create a new file from the Clipboard.
5. Your screenshot is now available to be saved as a png file. (I recommend removing the 20px status bar by cropping it from Photoshop or some other image-editing tool.)

That’s it!

PS. Others recommend just using the default OSX method for screen captures, but I don’t recommend it due to the fact that it’s hard to get the pixel sizes right.

Quick Submission Checklist for prepping iTunes Connect

dacapo — Sun, 09 Oct 2011 13:35:23 +0000

As I complete different iOS projects for clients, this checklist helps them to prep their iTunes Connect in advance, so that the app submission process goes smoothly.

1. Name of App (Exact App Name as it’ll appear on the iTunes App Store). May need to tweak if there is another app with the exact same name on the app store.

2. Name of App as it’ll appear under the icon on the device. (Recommend approx. 12 or fewer characters. It should resemble the app name above somewhat. I’ve seen an app meta-rejected for having a seemingly unrelated icon display name.)

3. Catchy description. Can be as long or as short as you want. (Please see other app descriptions on App Store for ideas.)

4. SEO Keywords: Up to 100 characters, including commas and spaces.

5. Category that the app will be in. Need to choose one, unless it’s a Game or an Educational app.

6. Copyright owner info

7. Support website (can be just the business website)

8. Support email address (can be just a contact email)

9. Pricing

10. iTunes Artwork (512×512 pixel png, flat, no transparency)

11. Screenshots. (320×460 or 320×480 pixels for iPhone and 768×1004 or 768×1024 for iPad)

If you get these prepped in advance, adding a new app to iTunes Connect becomes a smoother process. It’s also helpful to think about these in advance, to ensure that you’ve thought through everything from an app marketing perspective.

Resetting the device count in the iOS Developer Portal

dacapo — Sun, 09 Oct 2011 13:13:36 +0000

Things that happen once a year are easy to forget, especially if the procedure is somewhat complicated or poorly documented.

One such case is with the number of devices one can have registered in the iOS developer portal. Each developer account gets exactly 100 devices per year to register, no more, no less. (The exception is the iOS Enterprise Program, but with that, you are not allowed to publish to the App Store.)

This year, I’ve been particularly busy with providing development projects for clients. Normally, the “correct” way to register test devices is to prepare everything on the client’s iOS developer account. But for a quick build and test, the absolute quickest way is to just register the client’s device UDID (Getting the device UDID) registered to your developer account and deliver an ad hoc build to them. From the client’s perspective, this is quite painless.

As a developer, once a year, this can become a slight problem. Without de-registering older devices properly, it is possible to lock yourself into having a much lower limit to registering new devices.

Here is the official explanation from Apple, although I hate the way Apple worded it. (Apple iOS Program Renewals)

But basically, here is how it works.

When a new membership kicks in after you renew your membership, DO NOT add any new devices until you have removed all of the ones that you want to remove. Once you add a device, all of the existing devices will be re-registered.

So, when my program renewal is up later this month, I will:
1. Go into the iOS Developer Portal
2. Print out all of my existing UDIDs in case I need to re-register them later.
3. Remove all of the UDIDs except for the 3 devices that I own.
4. And then add in a new UDID at a later point in time.

Simple. But easy to forget!

PS. Removing your devices in the middle of a program year is not recommended. If you remove a device ID and have to re-add it, I believe that counts as 2 devices registered, so it’s really counter-productive. The best time to remove devices is right when your renewal kicks in.

Promo codes and app reviews – the loophole

dacapo — Sun, 09 Oct 2011 03:31:45 +0000

It used to be that developers would give away free promo codes and get a healthy number of positive reviews for their apps, kind of as a common courtesy. However, several months ago, that option became locked down. Overall, it’s for the better of the overall app consumer base, as leaving feedback for an app you got for free means that the review is likely to be skewed toward the positive side.

A couple weeks ago, I learned that this is not entirely true. There is one scenario in which people who downloaded apps via promo codes can still leave app review. The only way that I’m aware of is if a person redeems the promo code directly on iTunes (not on the App Store app on the iDevice) and subsequently writes a review through iTunes. Any other combination does not seem to work. Well, it’ll work only if a number of big “if”s are met, including whether the person will redeem the promo code from iTunes or from the App Store App. And then, the person has to remember and be willing to write a review for your app. Then, of course, the person has to attempt to do so through the iTunes interface. Very hard to get all three conditions to be met, if you ask me. But theoretically, it’s possible.

Now, only if I can share promo codes with only the people who are both willing and able to leave feedback. Maybe it’s better to forget about it and spend my time just writing code for my next app project. But, it’s still interesting to learn that loopholes do exist.

My favorite Steve Jobs’ quote

dacapo — Sun, 09 Oct 2011 02:49:05 +0000

With the passing of Steve Jobs this week, everyone has been commemorating his life and his legacy. My first memory of an Apple product was when my dad bought me the Apple IIc. It was the first laptop, if you will, of the Apple II series. Far ahead of its time.

I think I probably wanted a Mac even back then, but looking it up on Wikipedia, it looks like the first Mac went for $2495, whereas my humble Apple IIc went for $1295. Wow, prices were inflated back then. The insanely popular MBAs now go for what the Apple IIc used to go for, and even cheaper if you think about inflation.

So, what was my favorite Steve Jobs’ quote? There are several, but my favorite is also his shortest.

“Real artists ship.”

Apparently this was what he said to the team as they prepared to launch the first MacIntosh. There is a lot packed in those three words.

Point 1: Steve Jobs never saw his work as just a product. He saw it as artistry.

Point 2: Steve never confused a sense of artistry with mere aesthetic value. To him, what mattered was that the artistry was expressed as a final product.

Point 3: He didn’t just see himself as an artist. He rallied his team by bringing them up to his standards.

There is definitely a lot to learn from Steve Jobs. For that reason, I’m really looking forward to the upcoming authorized biography of Steve Jobs. I can’t help but think that part of his intensity must have contributed to his shortened life, and I don’t think I’d want to trade places with him if I really had to, but there is still a lot to be learned from his life.

“SEO Optimizing” Your App for iTunes – Part 3 (What Doesn’t Work)

dacapo — Sun, 09 Oct 2011 02:00:11 +0000

In my two previous posts (here and here), I described two methods for ensuring that your limited space for keywords are used effectively. It then hit me that there may be other advice on the Web worth reading. I can tell you that what I’ve found is either grossly inaccurate or outdated. Here are some so-called strategies that don’t really work.

Fallacy 1: ~~Make your company name SEO Friendly~~
Answer: You should not utilize your “company name” or “publisher name” to be SEO friendly. Why not? Because you only get one crack at the company name, and you can’t change it. So, if your first app has to do with “acing the GMAT” or something like that, it would be a completely odd thing to make GMAT a part of your company name. It would not only look weird, but you would also feel really weird when you release your second app, let’s say “acing the LSAT”. Get what I mean?

Fallacy 2: ~~Fill up your app description with SEO-smart words~~
Answer: Do not waste filling in your app description section with SEO-smart words. It doesn’t get picked up by the iTunes search engine! Keep your app description section clean and easy to read. Catchy, but not too long, because most people don’t spend too much time reading lengthy descriptions.

Fallacy 3: ~~Fill up your App Title and your Keywords section with SEO-friendly keywords.~~
Answer: Don’t repeat the words in your App Title in the keywords section. It is simply a waste of your valuable keyword space! It’s not as if the iTunes search engine checks for the # of times a keyword appears in your title and keyword section. The iTunes search engine only looks for the existence of a keyword and returns the results based on relative popularity (# of times app was downloaded).

So, there you have it, 3 common mistakes when doing SEO-optimization of your app.

“SEO Optimizing” App Keywords on iTunes App Store – Part 2

dacapo — Sun, 09 Oct 2011 01:27:06 +0000

In my previous post, I talked about the lamentable fact that the iTunes search engine is really unforgiving and makes you write both singular and plural forms of a keyword, or risk being left out of certain search results. Very important for getting your app noticed for single-word searches.

Of course, sometimes people search for phrases. In this scenario, iTunes is much more forgiving.

FACT 2: Phrase searches will take different combinations of your keywords.

Let’s say you have 3 terms in your keyword list, i.e., school, vacation, love.

If a person searches for “school vacation” or “school love” or “love school”, your app will be returned for all 3 conditions!

So that’s good news. It verifies that the ordering of the keywords does not matter. You can place them in whatever order you want. As long as a person is searching for multiple words (phrases), your app will be returned in the results.

Another tip: Don’t forget that you are limited to 100 characters, not 100 words. This is very limited space. Other than lengthening the App Title, which you could do at the risk of making your app title look spammy, you only have 100 bytes to play with. How to best utilize the 100-byte space? I recommend using either spaces or commas, but not both, to delimit the keywords.

Good: school,love,vacation (clearly delineates, my preferred method)
Okay: school love vacation (delineates, but my human eyes can’t follow well)
Not good: school, love, vacation (waste of space)

To summarize:

1. Be careful of singular versus plural. iTunes does not do searches based on partial strings. Only on exact strings.

2. Don’t worry about ordering of strings for phrase searching. iTunes does not care and will return search results based on different combinations of strings, as long as the customer is searching for phrases.

Good luck!