Unable to read symbols warning with XCode 3.2.5 and iOS 4.2.1

If you get one of the following messages in the console while starting your program : 

warning: Unable to read symbols for /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1 (8C148)/Symbols/usr/lib/info/dns.so (file not found).

or

warning: Unable to read symbols for /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1 (8C148)/Symbols/Developer/usr/lib/libXcodeDebuggerSupport.dylib (file not found).

These are known problems by Apple, but they shouldn't prevent debugging. I spent some time on trying to solve these problems before I realised that indeed debugging was still working. Even using the new "Collect" feature in the Organizer for an unknown (minor) iOS version did not solve this problem. I guess it's just a bug we must live with until the next release of XCode.

Posted via email from Tofodo Software

What the App Store really lacks

Now that Apple has released the App Store for Mac it is becoming even more clear that what it really needs to do in the promotional information is to allow for videos. So many software products use video to promote their features, it is really a big lack. At the least it should provide ways to embed video or provide video links.

Then again, this might put a strain on their content distribution network, and the cost might not be easy to offset with the margin they have for the store.

Posted via email from Tofodo Software

The Mac App Store, revolutionary or evolutionary ?

Apple has just released the new Mac App Store, a centralized way to distribute, purchase, install and update Mac applications, much in the same way you can now do it for the iPhone and iPad.

From a programmer's point of view, this is really the next logical step, as they already have the platform in place for the mobile devices, and as all the devices including the desktop computers use the same operating system, it's mostly a matter of adapting the technology to make it work on different screen sizes and with various restrictions in place.

Much has been written about the closed nature of the Apple application stores, and while it makes a lot of sense on the mobile devices, it remains to be seen how much of a good thing this can be for desktop applications. I think that a lot of the success of failure of this new store will depend on whether this is acceptable or not for the end users as well as the developers. Think for example of the number of "tweaking" applications available for Mac OS X. If these are not accepted in the store, surely developers will not be happy, and users will also suffer as they will not be able to get as much from the store in terms of choice.

Despite all these limitations, I think that this new application store is more revolutionary than evolutionary. It will be the first time a serious effort will be done to completely integrate an application store with an operating system, all this coming from the same vendor. Sure, MacUpdate or Bodega and others have tried to do this for a while, but their efforts never really took off, mostly because not every mac users can find them easily, without knowing about them. In the case of the new Apple built store, it will be installed by default on every Mac, and it will make it really easy for users to find new applications, and even better, get notified of updates, etc.

This is also great new for Mac users that have always suffered from lack of choice for applications. Before the Mac got to it's current marketshare, it was very difficult to find equivalent applications to Windows applications, mostly because the marketshare was smaller and developers wouldn't seriously target the Mac as revenue was not guaranteed. With an integrated application store, this could all change, and with Mac marketshare growing, this could definitely make it very interesting for developers.

A lot of existing iPhone and iPad developers will also be able to port their apps relatively easily, although they will have to refactor the front-ends, as the frameworks are not exactly the same. Despite this they already know the programming language (Objective C) and most of the UI building can be done in Interface Builder, so it shouldn't be that much of a port.

I think also that this new store is revolutionary, because if it does take off like the iPhone and iPad ones did, it will be immediately imitated by other OS vendors. Actually here Ubuntu is already a player in this space, but again, on Linux most of the stuff is free, so maybe there is no interest for developers to make any money there. On Windows however, you can be sure that Microsoft will be looking at Apple's effort very closely, and if they see that it is picking up, they might start integrating something similar. Of course for them it's always a bit more tricky, as somehow Microsoft always gets more heat for integrating things than Apple does (why this is is a mystery to me :)).

Anyway, exciting times on the desktop side for once, it will be definitely interesting to watch !

Posted via email from Tofodo Software

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