Be careful when using custom iPhone frameworks

In my previous post (http://tofodo.posterous.com/watch-out-for-iphone-deployment-target-defini), I went into details about the deployment target variables, and it's importance to be setup right. Despite this, I was still running into a strange issue. I was basically seeing the following compilation directives.

For the simulator :

-D__IPHONE_OS_VERSION_MIN_REQUIRED=20000

and for the device :

-miphoneos-version-min=2.0

I spent a *long* time trying to find where these were coming from, searching all over the iPhone SDK, my project files, everywhere, or at least I thought so. I then had the idea of creating an empty project and comparing the project information between the two. That is when I came across the fact that I was linking to an custom iPhone Framework that I use for AppShaker: json-framework. Curious, I went into the framework files and guess what I found in these ?

In ~/Library/SDKs/JSON/iphonesimulator.sdk/SDKSettings.plist :

<key>GCC_PRODUCT_TYPE_PREPROCESSOR_DEFINITIONS</key>

<string> __IPHONE_OS_VERSION_MIN_REQUIRED=20000</string>

and in ~/Library/SDKs/JSON/iphoneos.sdk/SDKSettings.plist :

<key>IPHONEOS_DEPLOYMENT_TARGET</key>

<string>2.0</string>

So there you have it ! What I had been searching for all this time. Seems like it was a very poor idea for this SDK to include such directives, because it means that they will always override your project settings. Looks like, although less clean, it is a better idea for the moment to copy the source files into your project, as I have been doing with ASIHttpRequest, than to link to a framework setup that can be quite obscure.

Posted via email from Tofodo Software

Posterous doesn't like #endif !

I just spent the last twenty minutes trying to understand why Posterous was systematically truncating my previous blog entry, when I was submitting it by mail. It is a blog entry with code extracts, and it seems that if didn't like the #endif macros that were included in the text. This is because, according to their FAQ :

"Strip out your signature by ending your post with #end. We won't post anything after that text."

Actually it seems that this is not exactly how it works, because I had multiple #endif statements and it was only truncating after the last entry. Anyway, to post this little problem I had to post via the web interface, as it was impossible to do it by email.

I think they should offer another type of marker than #end because it is quite common that people will want to post code extracts on Posterous.

Posted via web from Tofodo Software

Watch out for iPhone Deployment Target definition !

Yesterday, as I was working on an AppShaker update, I came across a really tricky problem, that I think quite a few of you might experience so I'm detailing it here.

What happened is that I updated to the latest version of ASIHttpRequest, and also to the latest version of XCode 3.2 for iPhone OS 3.1 and again my project stopped compiling. More precisely it was the following code from ASIHttpRequest.m that was generating an error :

// Obtain the list of proxies by running the autoconfiguration script

#if !TARGET_OS_IPHONE || __IPHONE_OS_VERSION_MIN_REQUIRED > __IPHONE_2_2

CFErrorRef err2 = NULL;

NSArray *proxies = [(NSArray *)CFNetworkCopyProxiesForAutoConfigurationScript((CFStringRef)script,(CFURLRef)theURL, &err2) autorelease];

if (err2) {

return nil;

}

#else

NSArray *proxies = [(NSArray *)CFNetworkCopyProxiesForAutoConfigurationScript((CFStringRef)script,(CFURLRef)theURL) autorelease];

#endif

Basically it was always compiling the "else" clause, despite the fact that I was compiling (or at least it seemed so) for OS 3.0, so we should be normally be in the first part of the clause. It was then failing because the version of the method being called was not the proper one. When looking at the error in detail, especially the command line that was being called, this is what was being generated in the case of compiling with the simulator :

CompileC "build/AppShaker.build/Debug-iphonesimulator/AppShaker Lite.build/Objects-normal/i386/ASIHTTPRequest.o" Classes/ASIHttpRequest/ASIHTTPRequest.m normal i386 objective-c com.apple.compilers.gcc.4_2

cd /Users/loom/Documents/work/iphone/AppShaker

setenv LANG en_US.US-ASCII

setenv PATH "/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"

/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.2 -x objective-c -arch i386 -fmessage-length=0 -pipe -std=c99 -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -D__IPHONE_OS_VERSION_MIN_REQUIRED=20000 -isysroot /var/folders/95/95xwCQ0mEeivSCrcsKn1i++++TI/-Caches-/com.apple.Xcode.501/CompositeSDKs/iphonesimulator-iPhoneSimulator3.0-aljhdklevtyfaoefjftiofmwffte -fvisibility=hidden -mmacosx-version-min=10.5 -gdwarf-2 -iquote "/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphonesimulator/AppShaker Lite.build/AppShakerLite-generated-files.hmap" "-I/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphonesimulator/AppShaker Lite.build/AppShakerLite-own-target-headers.hmap" "-I/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphonesimulator/AppShaker Lite.build/AppShakerLite-all-target-headers.hmap" -iquote "/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphonesimulator/AppShaker Lite.build/AppShakerLite-project-headers.hmap" -F/Users/loom/Documents/work/iphone/AppShaker/build/Debug-iphonesimulator -I/Users/loom/Documents/work/iphone/AppShaker/build/Debug-iphonesimulator/include -I../fbconnect-iphone/src "-I/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphonesimulator/AppShaker Lite.build/DerivedSources/i386" "-I/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphonesimulator/AppShaker Lite.build/DerivedSources" -DLITE_VERSION -include /var/folders/95/95xwCQ0mEeivSCrcsKn1i++++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/AppShaker_Prefix-audfaisngyebyfexxpoauqdgjasw/AppShaker_Prefix.pch -c /Users/loom/Documents/work/iphone/AppShaker/Classes/ASIHttpRequest/ASIHTTPRequest.m -o "/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphonesimulator/AppShaker Lite.build/Objects-normal/i386/ASIHTTPRequest.o"

and when compiling for the device, I got the following command line :

CompileC "build/AppShaker.build/Debug-iphoneos/AppShaker Lite.build/Objects-normal/armv6/ASIHTTPRequest.o" Classes/ASIHttpRequest/ASIHTTPRequest.m normal armv6 objective-c com.apple.compilers.gcc.4_2

cd /Users/loom/Documents/work/iphone/AppShaker

setenv LANG en_US.US-ASCII

setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"

/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -x objective-c -arch armv6 -fmessage-length=0 -pipe -std=c99 -Wno-trigraphs -fpascal-strings -O0 -Wreturn-type -Wunused-variable -isysroot /var/folders/95/95xwCQ0mEeivSCrcsKn1i++++TI/-Caches-/com.apple.Xcode.501/CompositeSDKs/iphoneos-iPhoneOS3.0-gxzvuzxhrjrauieejvpvjxrjejlf -fvisibility=hidden -gdwarf-2 -mthumb -miphoneos-version-min=2.0 -iquote "/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphoneos/AppShaker Lite.build/AppShakerLite-generated-files.hmap" "-I/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphoneos/AppShaker Lite.build/AppShakerLite-own-target-headers.hmap" "-I/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphoneos/AppShaker Lite.build/AppShakerLite-all-target-headers.hmap" -iquote "/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphoneos/AppShaker Lite.build/AppShakerLite-project-headers.hmap" -F/Users/loom/Documents/work/iphone/AppShaker/build/Debug-iphoneos -I/Users/loom/Documents/work/iphone/AppShaker/build/Debug-iphoneos/include -I../fbconnect-iphone/src "-I/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphoneos/AppShaker Lite.build/DerivedSources/armv6" "-I/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphoneos/AppShaker Lite.build/DerivedSources" -DLITE_VERSION -include /var/folders/95/95xwCQ0mEeivSCrcsKn1i++++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/AppShaker_Prefix-bgsrygfnnblyztcpvkeymcpfoigy/AppShaker_Prefix.pch -c /Users/loom/Documents/work/iphone/AppShaker/Classes/ASIHttpRequest/ASIHTTPRequest.m -o "/Users/loom/Documents/work/iphone/AppShaker/build/AppShaker.build/Debug-iphoneos/AppShaker Lite.build/Objects-normal/armv6/ASIHTTPRequest.o"

Then I looked at the system defininition for the __IPHONE_OS_VERSION_MIN_REQUIRED constant :

#ifndef __IPHONE_OS_VERSION_MIN_REQUIRED

#ifdef __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__

// compiler sets __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ when -miphoneos-version-min is used

#define __IPHONE_OS_VERSION_MIN_REQUIRED __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__

#endif

#endif

What is really interesting is that some nice engineer documented here in the comment that the environment constants comes from the -miphoneos-version-min command line option. So immediately I looked at the above command lines to figure out what the value was for those. In the case of the device compilation, indeed we can find it, and it's value is :

-miphoneos-version-min=2.0

In the case of the simulator, strangely it isn't generating the same command line and is instead directly defining the minimal OS version directly, as seen in the extract below :

-D__IPHONE_OS_VERSION_MIN_REQUIRED=20000

Why the two environment compile differently is still a mystery to me so if any readers can shed some light they are more than welcome.

When I saw the value being at minimal 2.0 I wondered where it could come from. I looked at my project build variables and I saw that I had multiple values for the IPHONEOS_DEPLOYMENT_TARGET variable, so I cleaned it up and removed all different levels. So basically this was what it looked like in the main project Info screen :

As it is NOT in bold, it means that the definition is using the default project compiler value, so I thought that was probably ok.

So I googled "iphoneos-version-min" and came across the following source code (http://www.opensource.apple.com/source/gcc_42/gcc_42-5566/gcc/config/darwin-driver.c?f=text), which is basically GCC patches contributed by Apple to the GNU compiler project. The interesting part is the following extract :

/* For iPhone OS, if no version number is specified, we default to

2.0. */

As this was the behavior I was seeing, I suspected that probably the default in the project info must not be correct. So I tried the following, which worked (!) : I went back to the project info, selected the "iPhone OS Deployment Target", the selected "iPhone OS 2.0" (or any different value, it doesn't matter, and then reselected "iPhone OS 3.0". This had the effect of making a definition at the project level, which is confirmed by the fact that the setting is now in bold, as illustrated below :

I then selected "Build -> Clean All Targets" and rebuilt all targets, and that was it !

So there it was, another obscure behavior of XCode. If others have this problem, please comment this blog entry, and I might then make a bug report to Apple, because this is really tricky to figure out.

Posted via email from Tofodo Software

Apple now checks keywords in iPhone app submissions

After a little more than 3 weeks of waiting, Apple has finally rejected the new version of TiltSnake Lite. I figure I am becoming quite the expert at getting my apps rejected, because it seems to be basically one of two submissions that gets rejected.

 But what is new is the reason : inappropriate keywords ! This is the first time I heard about Apple checking the keywords. I must say that here I understand a little the rejection because I did "cheat" a little, because of lot of other application developers were cheating in their keywords. I guess that Apple is really committed to improving the quality of searches in the App Store and therefore I understand that they start validating keywords. The problem is that there are already quite a few apps out there with invalid keywords, and so on updates it is quite possible that developers will get rejections for this new reason while it was acceptable before.

 For the details, here is a extract of the rejection email :

 "Thank you for submitting TiltSnake 1.3 to the App Store. We've reviewed TiltSnake 1.3 and determined that we cannot post this version of your iPhone application to the App Store at this time because of inappropriate 'Keywords' used to identify your application. We cannot post applications that contain irrelevant keywords in their search criteria. Keywords must be applicable to the application content. It would be appropriate to remove the word sexy from your 'Keywords'. "

Posted via email from Tofodo Software

Compilation error when upgrading to Snow Leopard

Today I just upgraded my development machine from Leopard to Snow Leopard, and upgraded the XCode environment from 3.0 to 3.2. Here are the steps I needed to perform : 

The SDK 3.0 is the only one supported, so if you had projects that were compiling against earlier SDKs, you will have to update them. Here are the basic steps to upgrading your project to a Snow Leopard environment : 

1. Download the Snow Leopard SDK & Install it

2. For each project, In the project info, switch the base SDK to 3.0

3. In each target, check in the info that the SDK is also 3.0

4. For each target, switch the compiler from GCC 4.0 to GCC 4.2 (or you get an obscure compilation error : UILocalizedIndexedCollation error: syntax error before 'AT_NAME' token)

5. Empty the cache in XCode

6. Clean all targets

This should be everything. Of course feel free to comment this post if you find any more steps or if I have missed something.

Posted via email from Tofodo Software

Watch your own ads Apple, spend less on marketing, fix the AppStore !

In the above ad, Apple makes fun of Microsoft that seems to be spending more on marketing Vista than fixing it's problems. Well I think the same could be said of the App Store. Isn't that ironic ? 

What if Apple spent as much money fixing the AppStore approval process and improving the developers tools as it spends advertising it ? Possibly the developers would be happy campers, and could avoid jailbreaking their phones to be able to create truly innovative and compelling applications. They are already doing amazing things in the confines of the quite limited sandbox, so imagine what they could do without those confines ?

In his blog post (http://joehewitt.com/post/innocent-until-proven-guilty/), Joe Hewitt (developer of the Facebook app) argues that Apple should get rid of the approval process entirely. As a rebuttal (http://mashable.com/2009/08/25/facebook-changes-iphone/), Ben Parr argues that Apple should improve it and offers solutions to improve it. I must say that my personal opinion is closer to Joe's than Ben's, because I think that any approval process in inherently hindering the pace of innovation and bug fixing. Ben even adds the idea that some developers, like Joe, should be given priority for approval, because they are "trustworthy". In this last argument, I am completely in disapproval ! One of the strong arguments for the App Store is that a small developer has a chance to get his great application out there and compete with large companies. It's this type of competition that is healthy in the software industry, and if Apple started giving "priorities" to large companies (and they probably are already in some cases), it would be another blow to small-time developers. And innovation often comes from small-time developers.

If you have read my other blog posts on this subject, you know that I find it quite hard to stay motivated on developing new and improving existing applications when the review process is so slow and impredictable. For example, it has now been, at the time of this writing, over 3 weeks for both the TiltSnake Lite and AppShaker Lite applications since they were submitted, and I have no news from Apple. Did my applications get lost somewhere, should I try to write (nobody answers anyway, so what's the point ?), or should I simply wait some more ? For the moment I am choosing to wait, but at the same time I don't really see why I would work on improving the applications further, since it is entirely possible that the existing versions might be rejected for some obscure reason, and I will have to backtrack all changes to re-submit them. We really need tighter feedback loops.

What can you do about this ? Well the best way to get Apple to change something is to voice your disapproval of the current situation. The more we are, the more negative press is out there, the more chances that Apple will respond. And they have started answering, especially with the FCC getting involved, so there is some hope...

Posted via email from Tofodo Software

Apple now resort to intimidation tactics to reject applications

In the midst of all the buzz around Apple responding to developer complaints and iPhone boycotts, I thought I would share what happened to me.

 In my case, Apple has resorted to intimidation tactics to reject an application.

 I have worked on and off, as a side to my day job to develop applications for the iPhone, and while there are plenty of problems I am willing to accept as a developer, the application approval process was always a frustrating one.

 I have developed a small "joke" application, called ShakeCharge, that simulates recharging the device by shaking it, much like some real flashlights that actually work that way. I had this idea when Apple started approving all kinds of fart apps, and thought that maybe I could make a few bucks and share a few laughs with some customers. I always made sure that I marketed the application so that the user would understand it was a joke. In the last version of the app, the main screen was a warning screen, that nobody could confuse for the real thing.

Fast forward to today. I get a call from a person at Apple (the same Richard that everyone has been mentioning), that said they were reviewing my application "ShakeCharge", and that I had submitted it multiple times without modifying it. The last time I did indeed do that, but all the previous times I made modifications to the application, to make sure that I would comply to every criteria.
 
The person on the phone told me : "Please don't ever re-submit this application, we will never accept it. Spend your time and energy on other applications." . I replied that I didn't understand the rejection as they had approved a very similar app that simulate recharging the battery with the screen acting as a solar panel. His reply was : "I am not authorized to engage in such a discussion". The call ended basically in us both agreeing that we would not agree.
 
For me this is a intimidation tactic. There is nothing in my application that violates the terms of the iPhone Developer Program. They are somehow threatened by this application, and I don't understand why. What is certain is that this Richard person is relaying scary messages to the developers and that however is in charge of these refusals should seriously reconsider, because as these horror stories accumulate, all the good developers will start looking elsewhere, leaving Apple with just the developers that will do anything to make a quick buck.

Posted via email from Tofodo Software