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).

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 !

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.

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.

 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'. "

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 a few weeks ago. 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.

9a7gyr5zxw