first iPhone app finally published !
by Orion Elenzil · 09/25/2009 (8:39 pm) · 8 comments
the app is sort of a continuation of this blog post, with the main difference being that the app is now touch-enabled and in the app store!
unsorted reflections on the process:
* apple makes the thickest, stickiest, god-awfullest red tape ever conceived by human minds.
i seriously lost track of how many certificates and counter-certificates were involved in getting this Free app published. i believe three. likewise the number of different developer portals and tools involved seemed way more than necessary, and figuring out how to navigate them took a bunch of time.
* the simulator is pretty awesome.
* i have to say that i'm not coming around to Objective-C. it just feels old and clunky.
* i'm currently just trying to get a feel for the basic capabilities of the device, so i'm using the stock SDK & OpenGL. i'm curious about getting set up with HaXe tho, as well as checking out other frameworks.
* i'm still trying to figure out where the performance bottlenecks of the device are. is it pixel fill ? (i don't think so) is it number of primitives ? maybe. is it number of OpenGL calls ? maybe. if i were to convert the 520-or-so pushMatrix(), translate(), rotate(), drawArrays(), popMatix() calls per frame into a shader, would performance increase ? (3gs)
* is there really no way to browse the app store in a web browser ?
* it's very frustrating that there's no way to distribute an app w/o going through the app store process.
I'm planning a couple apps for the future.
One is a sort of AR poker game, and should involve GPS, the camera, and a back-end. The other is just [yet another] front-end for the google image search API.
screenies:
unsorted reflections on the process:
* apple makes the thickest, stickiest, god-awfullest red tape ever conceived by human minds.
i seriously lost track of how many certificates and counter-certificates were involved in getting this Free app published. i believe three. likewise the number of different developer portals and tools involved seemed way more than necessary, and figuring out how to navigate them took a bunch of time.
* the simulator is pretty awesome.
* i have to say that i'm not coming around to Objective-C. it just feels old and clunky.
* i'm currently just trying to get a feel for the basic capabilities of the device, so i'm using the stock SDK & OpenGL. i'm curious about getting set up with HaXe tho, as well as checking out other frameworks.
* i'm still trying to figure out where the performance bottlenecks of the device are. is it pixel fill ? (i don't think so) is it number of primitives ? maybe. is it number of OpenGL calls ? maybe. if i were to convert the 520-or-so pushMatrix(), translate(), rotate(), drawArrays(), popMatix() calls per frame into a shader, would performance increase ? (3gs)
* is there really no way to browse the app store in a web browser ?
* it's very frustrating that there's no way to distribute an app w/o going through the app store process.
I'm planning a couple apps for the future.
One is a sort of AR poker game, and should involve GPS, the camera, and a back-end. The other is just [yet another] front-end for the google image search API.
screenies:
About the author
#2
I think you can distribute your app in more direct way but to a very limited number of persons. The app can be generated and then distributed by web download or by mail with a private key, that permits the user to install it directly on is iPhone/iPod Touch.
But you only got 100 private keys to use for a iPhone Dev license.
This way of distributing is made for testers, reviews…
Nicolas Buquet
www.buquet-net.com/cv/
09/26/2009 (4:38 am)
Congratulations for your first app on iPhone, Orion !I think you can distribute your app in more direct way but to a very limited number of persons. The app can be generated and then distributed by web download or by mail with a private key, that permits the user to install it directly on is iPhone/iPod Touch.
But you only got 100 private keys to use for a iPhone Dev license.
This way of distributing is made for testers, reviews…
Nicolas Buquet
www.buquet-net.com/cv/
#3
As for other frameworks and engines, there are a few 2D systems I like. Cocos2D is a basic framework for sprites, tiles, animation, menus and sound. You have the option to switch to 3D mode and just use it as a quick way to build menus for a GL game. Now supports TrueType fonts.
Then there's a company in Oregon making something called "Torque", with an iPhone variant of both the 2D and 3D engines. Costs more than the $0 price tag on Cocos2D, but has actual level/map editors that don't make you hate your life. Other tools are included, and the GUIs go beyond just a clicky button, unlike Cocos.
Basically anything based on OpenGL ES is going to be your best bet (Quartz may work for slower-moving games), and you can take pieces of frameworks and use in whatever basic framework you already have. The CocosDenshion sound system included with Cocos2D is easier to use than OpenAL. Chipmunk physics is generally usable with anything, and Chipmunk SpaceManager handles the tedious setup of the same.
No, iTunes is not directly available in the browser. There are services which let you view the top lists in your browser or on your iDevice, though. You can easily find the big ones by searching. AppVee and AppMiner help you find good and cheap stuff, respectively. Apple are fighting efforts to screen-scrape the content :(
If ObjC and CocoaTouch feels clunky, either start learning it better, or hide away the initial setup and code pure C/C++ logic :)
(There's a freakin' wonderful new feature in OS 3.1 called CADisplayLink which I'm evangelising everywhere - it gives you a perfectly 60/30fps synced mainloop. Push the latest :)
Optimisations: It's a different form of OpenGL, with lots of limitations. A nice trick there is to use byte values rather than floats for colours. If the range of inputs can be reduced to 0-255, or on/off (UV values in glTexCoordPointer()), you can also make it a GL_UNSIGNED_BYTE. Use vertex arrays to bundle up drawcalls. Use moderately sized sprite sheets/texture atlases and compress with PVRTC. Use PNGs only when the compressed textures look ugly on the device. The fewer floats and smaller bitsize values you can squeeze in, the faster the wee ARM processor can send it to the GPU.
There may be cases where Thumb code works better. Always give toggling that a try. The new generation iDevices has a different CPU with different floating point features, and if you compile code exclusively for those, you have a new optimisation for that. You can also make a universal binary (armv6+armv7) starting with OS 3.0, although I'm not sure if Apple approves that yet.
Xcode 3.2+iPhone OS 3.1 also gives you some more memory overview options in Instruments.
09/26/2009 (7:27 pm)
Congratulations on surviving the approval gauntlet :)As for other frameworks and engines, there are a few 2D systems I like. Cocos2D is a basic framework for sprites, tiles, animation, menus and sound. You have the option to switch to 3D mode and just use it as a quick way to build menus for a GL game. Now supports TrueType fonts.
Then there's a company in Oregon making something called "Torque", with an iPhone variant of both the 2D and 3D engines. Costs more than the $0 price tag on Cocos2D, but has actual level/map editors that don't make you hate your life. Other tools are included, and the GUIs go beyond just a clicky button, unlike Cocos.
Basically anything based on OpenGL ES is going to be your best bet (Quartz may work for slower-moving games), and you can take pieces of frameworks and use in whatever basic framework you already have. The CocosDenshion sound system included with Cocos2D is easier to use than OpenAL. Chipmunk physics is generally usable with anything, and Chipmunk SpaceManager handles the tedious setup of the same.
No, iTunes is not directly available in the browser. There are services which let you view the top lists in your browser or on your iDevice, though. You can easily find the big ones by searching. AppVee and AppMiner help you find good and cheap stuff, respectively. Apple are fighting efforts to screen-scrape the content :(
If ObjC and CocoaTouch feels clunky, either start learning it better, or hide away the initial setup and code pure C/C++ logic :)
(There's a freakin' wonderful new feature in OS 3.1 called CADisplayLink which I'm evangelising everywhere - it gives you a perfectly 60/30fps synced mainloop. Push the latest :)
Optimisations: It's a different form of OpenGL, with lots of limitations. A nice trick there is to use byte values rather than floats for colours. If the range of inputs can be reduced to 0-255, or on/off (UV values in glTexCoordPointer()), you can also make it a GL_UNSIGNED_BYTE. Use vertex arrays to bundle up drawcalls. Use moderately sized sprite sheets/texture atlases and compress with PVRTC. Use PNGs only when the compressed textures look ugly on the device. The fewer floats and smaller bitsize values you can squeeze in, the faster the wee ARM processor can send it to the GPU.
There may be cases where Thumb code works better. Always give toggling that a try. The new generation iDevices has a different CPU with different floating point features, and if you compile code exclusively for those, you have a new optimisation for that. You can also make a universal binary (armv6+armv7) starting with OS 3.0, although I'm not sure if Apple approves that yet.
Xcode 3.2+iPhone OS 3.1 also gives you some more memory overview options in Instruments.
#4
nicolas - yr right, i should check out the 100 installs thing. i worry that it requires physical access to the device and/or technical ability on the part of the recipient, which would make it inideal for beta-testing or casual distribution to friends.
ronny - thanks for all the great info!
re obj. c, i'm sure it'll become second nature if i keep using it long enough. however i'm currently much faster coding c/c++. is there a good place to go for basic examples of using OpenGL and the basic GUI framework from c++ ?
great tip on the bytes vs. floats & image formats, thanks.
thumb code - i didn't even know that existed. looks like it's on by default, i'll try turning it off and seeing if there's a performance change.
appVee is interesting.
i'm startled at the lack of search tools for the app store.
where is sort-by-price and sort-by-rating within a set of search results ? it must be some biz strategy on apple's part.
thanks again.
09/27/2009 (3:43 pm)
thanks for the replies guys !nicolas - yr right, i should check out the 100 installs thing. i worry that it requires physical access to the device and/or technical ability on the part of the recipient, which would make it inideal for beta-testing or casual distribution to friends.
ronny - thanks for all the great info!
re obj. c, i'm sure it'll become second nature if i keep using it long enough. however i'm currently much faster coding c/c++. is there a good place to go for basic examples of using OpenGL and the basic GUI framework from c++ ?
great tip on the bytes vs. floats & image formats, thanks.
thumb code - i didn't even know that existed. looks like it's on by default, i'll try turning it off and seeing if there's a performance change.
appVee is interesting.
i'm startled at the lack of search tools for the app store.
where is sort-by-price and sort-by-rating within a set of search results ? it must be some biz strategy on apple's part.
thanks again.
#5
09/27/2009 (7:46 pm)
C/C++ will pretty much be like you're used to. If you can wrap your head around OpenGL ES and the lack of some things (GL_INT, I think is one thing that's gone!), it's not so bad. I don't know any specific examples off the top of my head, but you can isolate all GL drawing code into C and C++ classes, inside .mm files with the bare minimum of glue. Just get the GLView running, and point to a function or method for the mainloop (NSTimer or CADisplayLink, or some method in the Director in Cocos2D). You should theoretically be able to avoid Cocoa most of the time. Input might require some Cocoa classes for input, though.
#6
09/29/2009 (11:58 am)
nice job!
#7
i'm bummed that it seems that even updates to an app take the full review time. for example, i made a minor change to the help-text, but it'll take two weeks before it goes out. or suppose i introduce a bug in a new version that makes the app crash in the wild. even if i fix it immediately, it'll be two weeks before the fix is out there. i'm not the world's biggest Agile fanboy, but fast turn-around times are definitely a good thing in my book.
09/29/2009 (3:05 pm)
thanks!i'm bummed that it seems that even updates to an app take the full review time. for example, i made a minor change to the help-text, but it'll take two weeks before it goes out. or suppose i introduce a bug in a new version that makes the app crash in the wild. even if i fix it immediately, it'll be two weeks before the fix is out there. i'm not the world's biggest Agile fanboy, but fast turn-around times are definitely a good thing in my book.
#8
09/29/2009 (3:07 pm)
whoa! apparently it's been downloaded about 130 times! probably due to this blog post. that's awesome. i love when people use something i wrote!
Associate Konrad Kiss
Bitgap Games