Injoit.com iPhone developers’ blog

Today we are having a real life test of our online high scores system because iCombat game version 1.2  got approved by Apple and there has been a flow of users populating the DB with their scores since then.

And suddenly it has stopped working - the online table wouldn’t show and as a result I had to learn a bit more about OAuth system we are using for the authentication purposes.

Read More

Here are some of the apps developed by us and already selling in the app store.

Also, some great apps are pending review and are to be seen soon!

iCombat - tanks game
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=309676121&mt=8

MyMakeup - make up application for kids
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=308690247&mt=8

Maxi Dice - dice game (Yatzee type)
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=302875350&mt=8

Thumb Wars - small touch game
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=305996685&mt=8

Jonas Wish - small fun app
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=305802591&mt=8

PopHead - small fun app
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=310731594&mt=8

We have updated our iPhone applications portfolio. More projects are currently in development or being reviewed by Apple testers, so check later for more exciting stuff developed by Injoit.

Bloody hell I’ve just spend more than two hours trying to figure out why Xcode won’t publish to my iPhone.

Tried everything - started with our checklist published earlier then lots of ritual dancing and read two big manuals by other guys:

http://www.24100.net/2009/02/iphone-sdk-mobile-provisioning-0xe800003a-0xe8000001/

http://www.codza.com/how-to-fix-iphone-code-signing-errors

Finally - being 100% sure everything is set up properly - used the idea of “Clean all” from the last link - and it worked! Nothing has been changed, I just quit the Xcode and removed everything from “Build” folder of my app! Then started it again, hit “Build” button and it worked!

Apple is evil. Thousands of developers spend hours losing time with all code signing thing. These lines from codza is one good example:

I was on a roll, all done in 30 minutes. A quick look at the clock: 11:30pm. I’ll quickly package it all up, submit my update, and pick out a dark comedy on Netflix instant watch…

Little did I know that for the next two hours I will be beaten, cubed and ground into hamburger meat by Apple engineering’s probably most ingenious attempt to one up Turing’s theory of the “halting problem”: code signing.

I was reading stackoverflow and found one great idea on making client-server based high scores system for your iPhone games so as this is something we would need to develop soon, I’m posting it here so not to forget and I’ll update this post when we come up with our own solution. Actually I had a similar idea but benzado has formulated it nicely so here it is:

One idea that might be Good Enough:

• Let Secret1, Secret2, Secret3 be any random strings.
• Let DeviceID be the iPhone’s unique device ID.
• Let Hash(Foo + Bar) mean I concatenate Foo and Bar and then compute a hash.

Then:

1. The first time the app talks to the server, it makes a request for a DevicePassword. iPhone sends: DeviceID, Hash(DeviceID + Secret1)
2. The server uses Secret1 to verify the request came from the app. If so, it generates a DevicePassword and saves the association between DeviceID and DevicePassword on the server.
3. The server replies: DevicePassword, Hash(DevicePassword + Secret2)
4. The app uses Secret2 to verify that the password came from the server. If so, it saves it.
5. To submit a score, iPhone sends: DeviceID, Score, Hash(Score + DevicePassword + Secret3)
6. The server verifies using Secret3 and the DevicePassword.

The advantage of the DevicePassword is that each device effectively has a unique secret, and if I didn’t know that it would make it harder to determine the secret by packet sniffing the submitted scores.

Also, in normal cases the app should only request a DevicePassword once per install, so you could easily identify suspicious requests for a DevicePassword or simply limit it to once per day.

Disclaimer: This solution is off the top of my head, so I can’t guarantee there isn’t a major flaw in this scheme.

Written by benzado

Currently, I’m trying to figure out the best way to make online highscores system for our clients without having to invent the bicycle. It seems however there is no great solution yet. I was looking into OpenID but the evidence that at the moment it doesn’t allow easy automated identification using the iPhone’s deviceId feature:

http://factoryjoe.com/blog/2008/01/13/the-openid-mobile-experience/

http://openid.net/pipermail/specs/2009-January/002688.html

so likely we will come up with our own solution something like Benzado mentioned above

Good news for those who think about developing their iPhone application and have this work outsourced due to various reasons. A client of ours, based in US, has started an online blog telling in real time about the development of iCombat game which we are working on currently.

This is a really exclusive blog to read as there are not much resources of this kind and you are able to track the development of a great iPhone game from the very beginning!

Check “making iCombat” - the best advice on outsourcing your iPhone development.

This is one of my favorite quotes :)   :

I posted an add and received about 10 responses within the first several days.  Some were developers just spamming me, others had relevant experience but were divided into a range of ratings from 3.5 to 5 out of 5.  I initially contacted the higher rated ones who had positive feedback on past assignments but with one from the Balkans I found that his English proficiency was far below what would be necessary to communicate effectively.  He clearly was very talented but I got the feeling he was using Google translate to answer my e-mails.  Another team from Pakistan spoke great English and they spent quite a bit of time on chat with me getting to understand the project.  I liked them but their estimate came in at 4 man months - roughly 2-3x longer than anybody else!  The process was tedious between getting NDA’s signed and sending out the specs to receive a quote (see Taking Care of the Legal Stuff entry) but I ended up with a few good options that I felt would work.

I decided on a team of developers from the Ukraine whom I had found worked on an application roughly similar to what I wanted to make.  I contacted them and immediately knew they would be easy to work with.  From their English level to experience with similar projects to their extensive list of published apps I knew Injoit could execute on what they promised.  For more about the process of finalizing the specs and signing up with them see the related entry Contract Signed!.  So far working with them has been great, they are timely and easy to communicate with so we will see what happens.

iCombat is a promising project which might become a bestseller in App Store so find the latest news on its development on its website and blog mentioned above. Feel free to comment and post your suggestions.

My livejournal friend TheKonst has posted his interpretation of Scrum management technology:

Original:

:-))

UPD: while our checklist managed to help some people, I’ve found the most explicit manual on this issue written by Ralf Rottman so posting a link to it here so that you may check it too (it’s much longer than our checklist but it covers the topic 100%):

http://www.24100.net/2009/02/iphone-sdk-mobile-provisioning-0xe800003a-0xe8000001/

And this is another good and fun guide, thanks to this guy I stopped to bother about Provisional profile not showing up in my Targets settings list - apparently they have removed it in 2.2.1 !!

http://www.codza.com/how-to-fix-iphone-code-signing-errors

I’ve written this for one of our clients and the client managed to load the app onto his iPhone device successfuly.  This being after studying the official Apple guides etc. So I’ve decided to publish our unofficial checklist here as this might be useful for others as well.

Sometimes people experience problems when publishing from their Xcode directly to their iPhone, or this issue might also arise when, as frequently in our case, developers are using one set of certificates and client, testing the app, uses their own certificate.

So, what you should have done to

check you did everything right to publish from your Xcode to your iPhone

in your apple developer web interface -
1. Added App ID
2. Added Device
3. Created certificates (1 private, 1 public, downloaded and added them to your keychain)
4. In Provisioning – added Profile
(specified your app id and device)
5. Downloaded the profile created.

In your Xcode
6. Added profile to the Organizer
7. In the project, go to Other resources / Resources and edit Info.plist – look for key “CFBundle Identifier”
replace its value with “YOUR ID”.* where “YOUR ID” taken from your apple web IDs – so if we have XXXXXXXX.com.injoit.appname, then we take XXXXXXXX and we make it:

before:
com.yourcompany.${PRODUCT_NAME:identifier}
after:
XXXXXXXX.*

In case getting any errors when publishing from XCode to iPhone, try disconnecting iPhone, relaunching both your iPhone and Xcode and trying again.

The whole procedure is described here:
http://developer.apple.com/iphone/manage/distribution/index.action
(Building your Application with Xcode for Distribution). Some steps in the guide (like setting Target) seem unnecessary and we can just publish w/o problems, just check you’ve done everything correctly in the web interface at Apple website, added your profile to the Organizer and also edit the .plist file.

Hope this helps.

Taras Filatov, CEO to Injoit.com.

Thanks to Vladimir who helped to write this checklist.

It has passed quite some time since Injoit has purchased its first real Mac which was Mac Mini. I’ve just got time to post some things and would like to post a photo of this cute thing as well.

This thing rocks as everything done by Apple. Most Mac Minis end up as music centres somewhere in the campus rooms under books and crisps packs while ours serves as a powerful development tool and a number of serious iPhone applications has already been developed with its help.

At photo you may see standard monitor, keyboard and mouse connected to our Mac Mini and Xcode with iPhone simulator running at the display.

Injoit company keeps pace with the newest trends and has made a significant step in extending its range of services with an offer of custom iPhone applications development.

In few months the talented coders of Injoit team have mastered the iPhone SDK including relevant technologies of Xcode, Cocoa Touch, Object C at a high professional level. New project flow processes
including Project Management and Quality Assurance have been standardized in order to serve best the
flawless development of great iPhone applications.

Click “More” to check our photos and read more about the event.

Read More