June 03, 2014

Swift - Upcoming Programming Language for iPhone and Mac Apps!

June 03, 2014/ Paul Solt

Apple just announced a new programming language called Swift. It's a future game changer, but it shouldn't effect your ability to learn how to create and ship iPhone apps today. I just submitted my first Mac app yesterday, but you can't do that with Swift today.

Swift won't be released until Fall 2014. Until then if you want to submit your first app to the App Store you need to start learning to program. Objective-C is the language that you should start with because it's mature and there is a lot of support on the web and videos to learn from. Programming is hard and it will take time to master, but you'll be in better shape if you start now. Apple has been working on some killer features that are making app development even easier, but we'll have to wait to take full advantage of those features.

Stick to Objective-C Until iOS 8 and Xcode 6 is Public

Programming is more than a language itself. Developers create collections of code files called frameworks, and we use these everyday on iPhone and Mac. The way you work with a framework isn't changing, so all of the skills that you learn with Objective-C directly translate to Swift. Rather than put off your dream of making an app you should start now.

I've worked for both Apple Inc. and Microsoft. At both companies we dogfood the latest software, and it's buggy. If you're a beginner the bugs and issues that come with beta software can be a real deal-breaker. Waiting for 4-5 beta releases or until Fall 2014 will make the learning experience a lot easier.

Swift Sneak Peak

I did explore a little bit of Swift and the Xcode Playground editor. It's neat, but auto-complete wasn't working for me. Using Objective-C code is still faster right now unless you memorize the method names and new API. Autocomplete is a tool that suggests things to you so that you can write code correctly and do it fast!

You can take a sneak peak with these resources on Swift. Apple published a programming guide on iBooks, and the Xcode 6 editor includes interactive documentation (live code). If you're adventurous you can install Xcode 6 Beta side-by-side with Xcode 5.

Official Documentation

Swift Programming language https://developer.apple.com/swift/
Xcode 6 https://developer.apple.com/xcode/

Resources

Make your iPhone Apps Today!

If you want to ship something today I would stick to Objective-C. Checkout my online courses for beginner iPhone programming and intermediate iPhone app programming.

June 02, 2014

ASO - App Search Optimization: The Quest for More Downloads with Keyword Optimization

June 02, 2014/ Paul Solt

Every app developer needs to think about App Search Optimization (ASO). You need to think about how other people perceive your app, and you need to speak their terminology for how they might describe it.

The competition is fierce on the App Store. Thousands of apps are being launched every week and many of them don't know about keyword search optimization. It's similar to Search Engine Optimization (SEO), but you have much less control. On the Apple App Store we are at the mercy of Apple's search algorithms and discovery features.

Before you can continue reading my post, I have two things I want you to do.

1. Take a moment and write down 10 terms that you believe describe the app.

You want to think about short words that you might use when you give a 30 second elevator pitch to anyone you might meet.

2. Ok, now I want you to write two sentences that explain your app to a 5th grader. What words are you using to explain it? Write those down too!

This is a brainstorming exercise which should help you open up the vocabulary and the way you can talk about your iPhone app. Different people use different words when they search for something. We need to uncover what relevant words can be used to describe your app idea. When we work on apps for so long, we sometimes forget how to relate the concept or essence to other people. The keyword search is where you learn about new words, ideas, or phrases that may be more descriptive to your users. These are potential words that people will search to find your app on the App Store.

The goal of this exercise is to get into the head of a potential customer, figure out what they might search on the App Store, and then leverage that keyword so you can appear in the list of apps. A good icon is important, since that’s going to help you standout in the search, but we’ll discuss icons in a separate post.

Limited Keyword Slots

There are only X number of slots for keywords for your app, and you need to make sure that you only use keywords once. Apple will use plural/singular forms, so you shouldn’t have to add unless you find less competition for one. It is important that you don’t just take my word for it. Go out and test in your app, it’s the only real way you can get data to show you what you should be doing.

App Store Submission Page has limited space for keywords and your App Name.

The goal of your keyword search is to uncover new words that are relevant to your app or game, and then use those. These are words that will be less common, but they will still get traffic.

Not every word that gets traffic will boost downloads. Sometimes when people search for a keyword they’re looking for a specific type of app, and if your app doesn’t appear to fit that category they may skip right over it.
You can’t compete for keywords that are popular in a new app. Unless the app goes viral, you will have to build up download traffic by choosing keywords that you can use to get new users. Keyword ranks are directly correlated to download and usage, new apps have neither, so you’ll have to build some traction.
We want to have our keywords rank in the top 10. Ranking higher than that will decrease the number of views your app will receive when a user searches on the App Store. How many times have you searched past 50, 100, or 500 apps when doing a search for a new app or idea? It’s similar to Google search page results, from my own experience I almost never go to the second page of results, and I hardly ever go beyond that page.

App Store Today

The current version of the App Store places all of the focus on the keywords in the title, and then the keywords in the 100 character keyword field.

There are 5 rookie mistakes when selecting keywords, and I know because I’ve done them before.

Don’t use spaces, only commas.
Don’t use phrases, Apple creates phrases for you.
Don’t use words in the title in your keyword list. Keep them different.
Don’t use popular keywords if your app gets no downloads.
Don't repeat a keyword!

Sensor Tower Keyword Suggestions helps you remove duplicate keywords for the limited 100 characters.

Bomb Dodge Preliminary Case Study on App Store Optimization for More Game Downloads

I haven't found any good guides to using keywords, titles, and App Store Optimization (ASO). To provide insight for other indie game developers or new iPhone and iPad app developers I am going to post about my experiences and take aways from trying to find better search ranking results with my games keywords. If successful I may explore changing keywords in my more popular photo app, Photo Table.

Bomb Dodge is a fun game (for me) that I have been working on with a friend (Mike Lyman). We wanted to build something that used finger drag gestures and had lots of explosions. That turned into a game where you try to protect a bomb, Bombee, from blowing up. There are obstacles that you need to avoid like fireballs and explosions. We launched our first version under a different name and updated it once.

Our latest version 1.2 is going to be live on the App Store soon, and it contains new animations, sound, music, art, and gameplay elements. We also revised the scoring system so that it is more fair and added some stats for competitive players.

Version History

Version 1.0: December 20th 2013
Update 1.1: February 11th 2014

Lifetime Bomb Dodge Stats through May 31st 2014

Downloads have been slow, and that was what I expected. I haven’t done any marketing and I really just wanted to get some initial feedback before we relaunched the game with all of the art and music that we’ve been working to finish.

Revenue: $9.80
Paid Downloads: 4 (2x $1.99 and 2x $4.99)
Free Downloads: 821
Total Downloads: 825

Bomb Dodge gets few downloads, but a festival booth gave us a nice bump in downloads.

We had a huge jump in downloads in the beginning of May from the ImagineRIT festival where we had a booth, 4 iPads, and 250 business cards with Bombee and the website for the game. Downloads are way slower than my app, Photo Table (447,000+ downloads).

ImagineRIT a festival booth made an impact on our keyword ranking. 38 up to 23 for the word "fling"

Over the past 60 days we had 334 downloads. I’ll exclude the ImagineRIT boost of ~108 downloads on May 3rd-4th, which gives us at 226 downloads. 226 downloads / 60 days is 3.77 downloads/day. It’s pretty slow and these numbers are something that you can expect for a new game or app without any promotion (Even with promotion it'll be slow if you don't know what your doing).

Let’s Try to Get More Downloads with Keyword Search Optimization

I’m exploring SensorTower.com to research new keywords and ranks. Previously I had used SearchMan.com but I never felt like I had good actionable insight from the data. It was hard to read and there wasn’t a lot of help. Sensor Tower has a really nice blog and their tools look much nicer from a usability and design standpoint.

My first step is to turn our original titles and keywords into a new set of titles and keywords to test. We’ll be doing some scientific method to hypothesize what changes we can make for the title and keyword. Later we’ll look at optimizing our icon (very important!) and screenshots (less important).

Downloads boost ranks for keywords. It might not seem obvious, but if your app isn’t getting downloads it’s not going to rank higher for a keyword like “fling”. Our goal with keyword optimization is to find keywords that your app can rank for, and to use them as new funnels for new customers to find your app. If those downloads boost your app downloads, then you can start to look at keywords that have more traffic and competition.

On May 4th and 5th we had a big boost in downloads from a booth at RIT’s ImagineRIT festival. Look at the impact on the keyword rank for “fling” a keyword in our app title. We put the keyword in both the title and the keyword field, but we should have only put it in one according to the current best practices from Sensor Tower.

Version Titles and Keywords

I don’t have all the data, but we’ll start to keep track of it from now on. You can see the titles and keywords that we started with, and next we’ll look into what keywords we can transition to.

Version 1.0

Protect the Bomb - Don't Explode! Smash Bombs, Dodge Explosions, and Avoid Fireballs

bomb,protect,flick,fire,explode,dodge,robot,fling,explosion,bombee,ball,cute,throw,smash,toss,wick

Version 1.1

Protect the Bomb - Don't Explode! Fling Bombs, Dodge Explosions, and Avoid Fireballs

dodge,steampunk,fling,hectic,smash,shield,fire,scientist,nuke,fireball,bomb,die,explode,protect,fun

Version 1.2 Keywords?

Now we’ll begin the journey of trying to follow best practices with our keywords using brain storming and Sensor Tower data.

I’ve started to compile a list of keywords, but I’m going to back to square one. I thought I had a good list, and that reusing keywords is a good thing, but it turns out you shouldn’t use a keyword that’s in your title as well as your keyword list.

We need to capture the essence of the game with keywords. To start the journey we’ll be brainstorming a lot of new ideas without any filters. I’ll post my starter keywords and then in the next post you’ll get to see my list of keywords after brainstorming. After that we’ll take a look at reworking the title to incorporate the keywords that we think we can boost the most. Title keywords have a bit of a preference over keywords in the list.

1.2 Keyword Ideas Revised and Revisited

Original 1.2 Keywords

fling,steampunk,dodge,kamikaze,fireball,bomb,explode,smash,bombs,explosion,explosions,fireballs,fire

Keyword Brainstorming Session 1

bombs,avoid,fireballs,explosion,explosions,fire ball,defense,defend, bomb,device,explosive,mine,missle,projectile,rocket,bombshell,grenade,ticker,atom,hydrogen,nuclear,charge,,dodge,plan,plot,scheme,strategy,,protect,defend,cover,preserve,safeguard,save,shield,shelter,secure,stonewall,watch,keep safe,stand guard,guard,watch over

Homework

Start a keyword list
For each word search thesaurus.com to find new keywords or concepts that you didn’t think about
Don’t filter anything that you think could be related, just write down word associations. We’ll filter next time.
If you have an app idea it’s important that you start thinking about how people can find your app. Write down those ideas!

Keyword Resources

May 30, 2014

iPhone App Memory Management - Why Do I Get Errors About Retain Release Dealloc in Xcode 5

May 30, 2014/ Paul Solt

In Xcode 4 and Xcode 5 an underrated developer tool for beginners is called ARC (Automatic Reference Counting). It simplifies a lot of the code and logic that we used to need to think about when we wrote apps.

Unfortunately, a lot of the code that you'll find on StackOverflow contains release, retain, autorelease, and [super dealloc]. When you try to copy that code into a new Xcode 5 project you'll get Xcode errors complaining about it. For the most part you can remove the extra nested method call to retain, release, autorelease, and you can delete anything that says [super dealloc].

If you want to see some examples I've posted some snippets of code of what you used to write and how it translates with the ARC code. Older projects should be updated to ARC because it makes it a lot easier to add open-source libraries that use ARC, or ARC code files.

Side note: I wrote Artwork Evolution before ARC was released and it was a royal pain trying to add some extra source code that was designed for ARC at the last minute before an art exhibit at Joe Bean Coffee Roasters. In the near future I plan on converting my app, Artwork Evolution, to ARC to make it easier to integrate some code that I've been using in my newer apps.

Example Xcode 5 Error Messages

NSDate *date = [[NSDate date] retain];

In non-ARC code we needed to explicitly tell the iPhone that we needed to hold onto memory so that we could do calculations or respond to user input. You'll see a lot of code littered with retain calls to make sure the app doesn't crash.

ARC: In ARC code we can remove all of these retain statements and make the code easier to follow and read.

'retain' is unavailable: not available in automatic reference counting mode
ARC forbids explicit message send of 'retain'

Rewrite the code as:

NSDate *date = [[NSDate date] retain];  // Non-ARC

NSDate *date = [NSDate date]; // ARC

NSDate *date = [[[NSDate alloc] init] retain]; // Non-ARC

NSDate *date = [[NSDate alloc] init]; // ARC

Note: With ARC, both [[NSDate alloc] init] and [NSDate date] behave the same. You can make your code more concise by using the static convenience method [NSDate date].

[image release];

Release was used to let the system know that you were done with memory. This allowed the memory to be used for other programs or other parts of your app. If you forgot to do these calls you ended up with memory leaks, and eventually your app would crash because it didn't have any memory to use.

ARC: In ARC code you can safely remove any calls to release.

'release' is unavailable: not available in automatic reference counting mode
ARC forbids explicit message send of 'release'

// Non-ARC
UIImage *image = [UIImage imageNamed:@"BombDodge.png"];
self.logoImageView.image = image;
[image release];

// ARC
UIImage *image = [UIImage imageNamed:@"BombDodge.png"];
self.logoImageView.image = image;

[super dealloc];

In non-ARC code we had to make sure to call the super method of dealloc to finish cleaning up our memory. If you didn't do this and didn't release objects that you were finished using you would have memory leaks.

ARC: In ARC code we don't, so you can safely remove those calls in your classes or sample code you copy/paste from StackOverflow. You can also remove any calls to release or objects set to nil.

ARC forbids explicit message send of 'dealloc'

// Non-ARC
- (void)dealloc {
    [super dealloc];
    
    [image release];
    image = nil;
    
    [self closeNetworkConnection];
}

// ARC
-(void)dealloc {
    [self closeNetworkConnection];
}

ARC: There are two special cases that you may want to keep the dealloc method (if it's empty you don't need it).

If you need to close down a network connection, socket, database, etc. You can use the dealloc method as a hook to trigger that action.
If you set any delegate objects that don't use a "weak" property modifier like the UITableView delegate or dataSource, you may want to set those to nil. You can run into situations with KVO or object lifetime where the class you created doesn't live as long as the UITableView class. In that case the UITableView object might send a message to your deallocated object, which can cause a crash.

// UITableView property is not weak!
@property(nonatomic, assign) id dataSource

// Custom dealloc to nil out the property to prevent crashes
- (void)dealloc {
    self.tableView.dataSource = nil;
    self.tableView.delegate = nil;
}

[myObject autorelease];

A lot of times when we worked with memory management, we used the auto release pools, which allowed us to use memory without having to do retain/release methods. There's a convention to how these methods were named, and your using them when you use something like [NSDate date]. The object will be alive for the scope of where it's used, unless you make an explicit retain call.

FIX: With ARC we don't need to worry about these old conventions and can just remove the extra method call to autorelease.

'autorelease' is unavailable: not available in automatic reference counting mode
ARC forbids explicit message send of 'autorelease'

// Non-ARC
+ (MyObject)myObject {
    MyObject *myObject = [[MyObject alloc] init];
    myObject.title = @"A title";
    myObject.on = NO;
    return [myObject autorelease];
}

// ARC
+ (MyObject)sampleObject {
    MyObject *myObject = [[MyObject alloc] init];
    myObject.title = @"A title";
    myObject.on = NO;
    return myObject;
}

Conclusion

When you copy/paste code from old textbooks or StackOverflow you may have to clean up the code to get it to work in the latest versions of Xcode 4 or Xcode 5+.

ARC is Automatic Reference Counting and it saves you a lot of time thinking about who "owns" a piece of memory (to store images, text, numbers, etc) in your apps. You can instead focus on how the logic of the app will work, how it will save data, how it will transition between screens, how it will animate and help the user accomplish a task.

Blog