Tuesday, August 11, 2015

Moore & the MacBook Air

I'm writing this on a 13-inch, Mid 2011 MacBook Air.
Recently I started looking at a new laptop. So, I compared the specs between the newest 13-inch MacBook Air and mine. Here they are (default configurations):

1.6GHz dual-core Intel Core i5 with 3MB shared L3 cache
2GB or 4GB of 1333MHz DDR3 onboard memory
Intel HD Graphics 3000
64GB or 128GB flash storage 

1.6GHz dual-core Intel Core i5 (Turbo Boost up to 2.7GHz) with 3MB shared L3 cache
4GB of 1600MHz LPDDR3 onboard memory
Intel HD Graphics 6000
128 GB PCIe-flashopslag

You basically get the same laptop with a better graphics card.
Sure, you now get Intel's Turbo Boost technology, but that's about it.

What about the benchmarks?
So I looked at the benchmarks. I used the Geekbench browser to check aggregated benchmark data.

MacBook Air Mid 2011 averages about 1800 
MacBook Air Early 2015 averages about 2400
Which equals a 33% increase in performance.

Whatever happened to Moore's Law?
Moore's Law states that the number of transistors doubles every two years. Thus from 2011-2015 the number should have increased 4-fold. Of course, due to increased complexity in connecting transistors, this would not result in a 4-fold increase in CPU power, but a 2-fold increase wouldn't be bad. According to Pollack's Rule (regarding microprocessor advances), this number would be even higher (albeit not much).

However, what I'm seeing here is not a 300%, not even a 100%, but a 33% increase in performance after 4 years.

What has happened?
Could someone enlighten me what has happened? Why is the performance lagging?
Have the transistors shrunk, thus allowing lower power consumption? Or has the power of the GPU increased significantly?

Let me know what you think below.

*Higher scores are better, with double the score indicating double the performance.

Friday, November 22, 2013

Why We Build Yet Another PDF App

There are over 4 gazillion PDF apps in the Apple Store. So why would anyone spend more than a year developing and marketing yet another PDF app???

There is NO app for that...
I do quite a lot of research. When studying or doing research, I usually use two or more documents at the same time. One as the document I'm studying, and the other as a reference. So I started looking for an app that would allow me to show two PDFs side-by-side and annotate them. Guess what!? There is NO app for that...

More than 1 million apps in the App Store...
Just saw that there are over a million apps in the app store (link). So how could it be that the app I was looking for was non-existent? No idea. There should be loads of persons studying, reviewing, doing research that could use a side-by-side PDF app. That’s why we’ve developed Easy Annotate.

We decide to develop ourselves...
Together with some friends we thus decided to develop our own iPad app. It would be of great use to us, and hopefully for many others. We had already developed an iPhone game, so we had a little experience, but none in productivity apps.

We've launched...
After developing for about a year, this week (20th november) we launched our app, Easy Annotate
It allows two PDFs to be shown, studied and linked side-by-side. And while we were on it, we added full dropbox support, to easily get files from our desktop to our app. It fulfills our needs and we hope it helps many more. 

There are still unserved markets in the App Store.When you're looking for functionality and can't find it, don't complain. Fill the gap.

Have Fun & Keep Koding!  
Freek Sanders.
Easy Annotate

Monday, July 15, 2013

Asynchronous Synchronization - A Warning !

In my last post, Asynchronous Synchronization, I explained how to wait for an I/O process to finish before resuming your app.

This works fine, unless you're working with false assumptions.
And that's what I'm writing about today.

Taking the same code sample as in Asynchronous Synchronization:

 - (void)actionOnDocument:(void (^)(PDFDocument *pdfDoc))actionHandler  
   __block bool isFileOpened = NO;  
   [doc openWithCompletionHandler:^(BOOL success) {  
     if (success) {  
       // save and close  
       [doc saveWithCompletion:^(BOOL success) {  
         isFileOpened = YES;  
     else {  
       isFileOpened = YES;  
   // loop-lock  
     [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];  

Now the problem: What if the local 'doc' variable turns out to be NIL ???

I had this issue today. After hours of hunting for memory problems, this was the problem.

What happens when doc is nil:

1 - doc is nil
2 - openWithCompletionHandler is called on a nil-object (i.e. nothing happens)
3 - the completion handler is never called
4 - isFileOpened remains NO forever
5 - the app remains in the while-loop forever
6 - we have a memory problem ;)

In this case the solution was simple. Encapsulate the whole function in a if(doc){...} caption, and we're safe.

This reminds me of why while(...) loops are so dangerous ;)

Have Fun & Keep Koding!  
Freek Sanders.

Monday, July 8, 2013

Asynchronous Synchronization

Asynchronous is the way to go!
Blocking synchronization functions are evil!

Usually these statements are true. Especially when handling I/O, blocking function calls can bog down your code.

But there are exception.
Sometimes your application can only continue AFTER a file is opened / saved / closed / etc.
This is usually where completion handlers come in handy. With these you can perform actions after the opening / saving / etc has been completed.

But once in a while, you need everything to wait until some I/O is finished. How do you go about this.

Here's some magic:

 - (void)actionOnDocument:(void (^)(PDFDocument *pdfDoc))actionHandler  
   __block bool isFileOpened = NO;  
   [doc openWithCompletionHandler:^(BOOL success) {  
     if (success) {  
       // save and close  
       [doc saveWithCompletion:^(BOOL success) {  
         isFileOpened = YES;  
     else {  
       isFileOpened = YES;  
   // loop-lock  
     [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];  

As you see, we want to perform some kind of action on a PDFDocument. However, we also want to make sure that the application does not continue before this function is completed (and the document is closed again).

The secret here is to run a check in a loop. Of course this loop should not check continually as that would suck up all resources. Instead we check every little while if something has changed in the status of the isFileOpened value.

Now we build synchronization into an asynchronous function.

Have Fun & Keep Koding!  
Freek Sanders.

Wednesday, July 3, 2013

Exploring App Space Usage

Currently we're working on a new PDF application (top secret).
One of the issues we ran into was the large amount of space the app uses.

Of course, loads of PDF's use loads of space. Still it was very improbable that the files I had imported to 830 MB!

The size of our App's Documents & Data ran over 830 MB!!!
(find this info in: iPad -> Settings -> General -> Usage -> App Name)

I needed to know what was eating this space, but had no idea how.
Then, this morning while debugging I mis-clicked something in XCode, and suddenly found what I was looking for.

How to explore your App Space Usage

  1. Connect your iPad / iPhone to your development machine
  2. Open XCode
  3. Open the Organizer (in XCode: Window -> Organizer)
  4. Go to Devices (top menu)
  5. Go to your iPad / iPhone (left menu)
  6. Go to Applications
  7. Now you'll see a list of all the apps you've developed and their data files (see image)
  8. By clicking the Download button in the bottom, you can download all the files in the App.

Problem Found

After downloading all the files, I quickly found the problem. All the PDF's were being cached and the cache had become more than 500 MB.

Solution: purge the cache on every App restart.
Simple solution, bye bye problematic space usage ;)

Do you have any suggestions or comments?
Don't hesitate to leave them!

Success & Keep Koding!
Freek Sanders.

Monday, July 1, 2013

How NOT to Launch a Game

Our game launched last year. Well... launched?
It's more like it was vomited on the App Store and died there.

What did we do? What was the result? Why was this stupid?

Launch day!

We launched our flag ship game MakeMeBlue in 2012.
We did no marketing whatsoever. Well, we told some friends about it but that's all. We hoped to launch soft and to grow our sales gradually as persons would download the game, play it and tell their friends about it.

We did not have a website
We did not write to game review sites
We did not have a youtube channel / facebook fan page / twitter account
We did not have an advertisement campaign

Why this is Bad?

This strategy stinks.

Even if people would love the game, they need to find it before they can love it. You can't tell your friends about games you don't know.

There are thousands and thousands of games on the App Store.Most gamers don't go through lists for hours and hours to find your game. Why would they? They just look at the top 10 or 100 and download something that looks nice. Or their friends did and told them about it.

This strategy is a certain path to take if you want to fail. And fail we did, just look at these wonderful statistics...

The Results

The first week reaped most downloads, with days ranging in the 20 downloads. We also had one day with about 60 downloads when testing out facebook integration.


Total downloads last half year: 336
Total in-app purchases after one year: € 3.01
Total iAd income after one year: € 3.05
Total admob income after one year: $6.35 (17.382 ad requests)

Lesson Learned

Actually it's pretty amazing that more than 300 persons were able to find our app and downloaded it. Wonder how they found it!?

The main lesson I learned is that marketing is vital to the success of any app. Thus with version 2.0 of our game we decided to relaunch it and spend more time on marketing.

We now have a website
We now wrote to game review sites
We now have a youtube channel / facebook fan page / twitter account
We now launched an advertisement campaign

The result of this?
We'll find out soon and let you know.

Do you have any stories or advice to share?
Please post it so we can all learn.

Success & Keep Koding!
Freek Sanders.

How to Build an iOS Game

Before you start, please read the warning notes in my last post: Why you should NOT build an iOS game

So, we've got that covered, and you're obviously obstinate about building an iOS game anyway.

Buiding an iOS app is not that hard if you know what you're doing. If you don't it is. I came from the latter position, and am happy to make the road somewhat smoother.

What to do:

1. Get a Mac

Yep, if you don't have one yet, you need to get one. iOS development can only be done on a OSX system, thus get a MacBook or something.

2. Get an iPhone / iPad

It's nearly impossible to develop a good app without being able to test it on the final product. So if you're building an iPhone game, you need an iPhone. Building an iPad game? Get an iPad.

3. Get the Tools

Download the most recent XCode application for your (shiny new?) mac. Go to the Mac App Store and type in XCode.

4. Get the SDK's

This step depends on you're game. In most cases it's an excellent idea to get a gamekit SDK to do much of the tedious work for you. It helps getting the graphics and sound together and aids in making animated transitions, etc easier. My pick was Kobold2D, which includes Cocos2D. It's free and you can download it at: http://www.kobold2d.com. At the moment it doesn't support 3D animations so if you need those, you need to get a different SDK. (most iOS games do without 3D anyway, see Angry Birds, Hay Day, etc and only use 2D images). Another popular option is to buy the Unity SDK. It's being used in many games as well. Check which fits your need best.

Make sure that the SDK you pick is able to do what you want. Do not save a couple of bucks on the SDK, just to spend weeks or months programming the missing features.

5. Get an iOS Developer License

It's needed to put your app on the App Store. Also useful if you need to ask question to the Apple Developer staff. Where to get it: https://developer.apple.com

6. Learn Objective C

To build an iOS app you need to program in Objective C. Get to know the language and the possibilities before starting out on your dream app. It saves you from having to keep rewriting parts of it.

Assuming you can programming already, I found the video tutorials by Paul Hegarty fantastic. You can download them for free here: iTunes Paul Hegarty Following these will help you to build simple iOS apps. Another wonderful resource is the site of Ray Wenderlich. Once you've mastered the basics, let Google be your friend ;) If you can't program yet, the tutorials of Paul Hegarty might be steep learning curve. Not impossible, just hard. Maybe it'll be a better starting point to take some programming classes off or online and to follow some basic tutorials.

7. Get to Know the SDK  

Get to know how to do stuff with the SDK you chose. Follow some tutorials and see the best practices. Again, Ray Wenderlich has some good ones for the Kobold2D/Cocos2D SDK.

8. Think Out the Game

Coding costs lots of time. Changing plans midway costs lots of time. Thus, write down you plans beforehand. Try to think out as much as possible before starting out.
  • What's the goal of the game?
  • Why would I play it again? 
  • How do I earn points? 
  • Do I compete against others or myself? How do I compete? 
  • Is the game too hard? Too easy? 
  • Is the game paid for/free? 
  • Do I want in-app purchases? If yes, why? where? Why would someone buy them?  

9. Marketing

Yes, you need to start marketing before you start building.
Unless of course you don't mind if nobody plays it. Hoping to make the top app lists by chance is like hoping to win the lottery. Not the best of business plans.

Ask yourself:
  • What's the earning model for this game? (free with ads, paid, in-app purchases) 
  • Who would play this game?
  • How can I reach these players?
  • Do they visit certain blogs, websites, read certain magazines?
  • Identify ways you can get to the pottential end users 
  • Build a teaser website 
  • Build a facebook page, twitter account, blog, etc.
  • Get in contact with your future users and keep them updated on the progress of your game
  • Build an audience before you launch, so users will download the game when it launches
  • Bring out teaser images, videos, etc.
  • Keep doing this until you launch
Marketing your app is the hardest and most overlooked step in developing a successful game. You can find more info on how NOT to do it here.

10. Draw the Game

Don't save time on planning. The more you know in advance, the better. Draw out all the game transitions. Draw out all the graphics.

  • How does the menu look?
  • How does the game background look?
  • How do the controls work?
  • What does the player see on launch?
  • Where are all the labels located?
  • How do you transition from screen-to-screen?
  • When and where is sound played?  

11. Design the Software

Before starting to code, always design the software first. It saves time later on.
  • How will you save data?
  • Do you need a database? If so, what fields, etc do I need?
  • What classes are you going to need? What functions?
  • Do you need additional SDK's for things such as Facebook integration?
  • What settings will you allow? Can you save them in NSUserDefaults?
  • How will you load images? As seperate files? As sprite sheets?
  • What about sound? How will you load it?  

12. Design the Graphics

Though luck creating your own graphics. Unless you're a graphical artist this is probably not your cup of tea.

This leaves three options:
  • Make it yourself anyway and suffer with bad graphics (really bad idea)
  • Hire someone to do the graphics. Make sure you're on the same line regarding the image your game needs to portrait. This is a good option if you have the budget and want to create a specific/unique look for your game.
  • Buy graphics online. Many graphics such as buttons, icons, etc can be bought online at a reasonable price. Don't spend hours designing a bad looking version of a button that costs $8 to download.  

13. Create the Sound

Like for graphics, you probably are not a sound magician. So again, take you're pick of the above three options.

14. Build the Game

With all the previous steps taken, you should now know how to build the game.

15. Test, Test, Test Again  

A game that crashes is a bad game. The following steps should take care of the most obvious mistakes.
  • Try all different ways of playing your game.
  • Finish the game multiple times.
  • Press all the buttons in random and various orders  

16. Get Dumb Users

Yep, your nemesis as developer is the end user.
They will use your game in a way you did not expect and not use it in the way you did expect.
They will ignore your instructions and help buttons.
They will crash the game in ways you can't.
They won't understand the menu.
They will get bored after one game.

Make sure you tested the game on real life users. Don't test just on your co-developers or on your boss. Test the game on persons who have never seen it before. Don't explain the game. If you need to explain it, you're lost. Ask them to criticize anything about the game. What do they like? What do they dislike?

How to find these users?
  • Friends
  • Family
  • Co-workers from different departments (finance for example)
  • Online (distribute the game for free to beta-testers)  

17. Get it On the App Store

Upload your app to the App Store. Don't make the game pubic yet, as you need to market your game

18. Market the Game

The hardest part of it all. This is a whole different story all together. Read the story.

19. Get a Swiss Bank Account / Enroll for Unemployment Benefits

(in case of the former, don't forget me ;))

Any steps I missed?
Do you have any suggestions?
If you're developing an app, keep me posted!
Please leave your comments below.

Success & Keep Koding!
Freek Sanders