4 ms·

Disclaimer -- I am not an iPhone developer, why? Two reasons: 1.) I don't own a Mac and 2.) I don't know objective-c. Even though I can't build iPhone applicat

Disclaimer -- I am not an iPhone developer, why? Two reasons: 1.) I don't own a Mac and 2.) I don't know objective-c. Even though I can't build iPhone applications, to me this ban makes sense for the following reasons: 1.) Limits the total number of applications. Apple knows that the "100,000+ apps" is just marketing. How many unit conversion applications do you need or does Apple want clogging up their approval process. 2.) Reduces the velocity of the application submissions. Having a more controlled ecosystem means that everything isn't done at once. This is core to Apples strategy. Roll things out in phases; build features that people want over time. Cut&Paste, Multi-tasking... 3.) Forces people develop iPhone applications on Mac hardware. 4.) The more layers between you and the developers building the applications increases compatibility issues, which are out of your control. 5.) The more layers between you and the developers building the applications decreases the speed at which applications can take advantage of new features. Apple releases a new api now any developer using a 3rd party framework needs to wait for that framework to support the new API. This impacts the significance of the new feature.

mrbad101 16y ago
Very very well put.
rimantas 16y ago
#5 makes a lot of sense and is often overlooked. The argument often is that it is not the tools that determine the quality, of the app, but let's see: Adobe CS5 Flash2iPhone is developed without iPhone OS 4 in sight. The main target users for it are those who are not familiar with iPhone OS and frameworks and would enjoy just pushing a button and letting the tool to do the rest. The timing is such, that a flood of apps developed this way would arrive just in time iPhone OS 4 comes out. End user does not know and does not care which tools the App was developed in. No surprise this does not look pretty in Apple's eyes. I and cannot imagine Flash2iPhone style of app producing anything about mediocre. If it targets Android too — even more so. This way all you can get is unisex, unisize sportswear. Apple wants tailor suits and designer dresses.
- Tichy 16y ago
  What if my app doesn't need all the latest features? I don't see how this argument makes sense. After all, competing SDKs don't force their users to stick to them. If somebody has already written a couple of Flash apps for iPhone, but now wants to program a 3d shooter, nobody is stopping him from switching to Objective-C.
  - pohl 16y ago
    The needs of the many outweigh the needs of the few, or the one.
    - Tichy 16y ago
      I don't understand the logical step here, I am afraid?
mojuba 16y ago
Speaking of compatibility layers, there is one very direct consequence of being inefficient on a mobile platform: battery life. I've become somewhat sensitive to what I'm doing on my computer since I started using a laptop at home instead of a desktop computer. I usually avoid watching long videos or generally using any Flash app not only because it eats up power terribly when it works, but I may find a defunct Flash process hanging there eating up some 20% of CPU even after I close the page with Flash. The problem seems to have gone away lately, but bugs are bugs, you can't expect exceptional quality from Adobe. Neither from any other developer, especially if we are talking about cross-platform runtimes. Apple's decision starts making some sense to me now (I don't develop for iPhone, so the ongoing drama is rather distant for me). The choice of languages - C/C++/Objective-C - clearly indicates that Apple wants efficiency, not just quality. Just add one layer between the language and the CPU (e.g. a virtual machine) and your phone's battery will die 5 times faster. I'm sorry for the dynamic language folks, but we are back to the era of bits and bytes, at least when it comes to smaller mobile devices. I think smarter manufacturers of mobile devices will do something about it pretty soon, once they see the boost of quality in the iPhone market. Provided that actually happens, of course.
- lispm 16y ago
  That's also 'Unfug'. Flash is just bad - especially if it does not use any hardware acceleration offered by the machine for video decoding. Battery life is not much affected by a dynamic language. Because no one with a clear mind will implement things like decoding of video in a dynamic language. But what people want is to implement GAME LOGIC in another language and not in C. The real battery life that matters is based on costly processes (like flash) and using costly services. Navigation is such a thing. There are many many applications for Navigation. ALL of them are a huge source of emptying your battery. I have used a single navigation application presenting a map and recording my track - battery life goes down to two hours. The reason is the screen, the internet connection for the map and the GPS receiver - all demanding power. But people want to use those things. So in a car the iPhone gets electricity from the car. On a bike there are electricity adapters also. There is NO reason to assume that a software written in a high-level language and translated to C will empty battery five times faster. YOU CAN WRITE BATTERY EMPTYING SOFTWARE IN ANY LANGUAGE - AND SOME OF THESE APPLICATIONS ARE VERY USEFUL - LIKE NAVIGATION APPLICATIONS. Take for example a program for the iPad that plots complicated mathematical formulas. Apple forbids translating the formulas to machine code on the iPad - because that would implement another programming language and runtime on the iPad. So Apple's restriction SLOWS things down. At the same time besides computing the formula the plotting application does mostly calling UI function (drawing, 3d stuff, etc.) and waits for user interaction (zooming, rotating, ...). You can write that part in any language - it is mostly calling platform functionality. So in this domain it either don't matter (because the UI code is mostly calling to the platform) or is getting worse because of Apple's policies (because you can't compile complicated formulas on the device, because that would violate Apple's developer restrictions).
lispm 16y ago
If Apple wants to limit the total amount of applications and at the same time improve the quality, they could get rid of the literally thousands of trivial books that are each an individual application. This could be for example done by forcing them to use in-app payment for loading new books or finding another organization principle. There are relatively few conversion applications in comparison. Conversion applications are really not a problem. How about the twenty or more music sequencer applications? Currently I would not easily find out which one is really good. Should Apple limit people submitting these applications? I'd rather have the market decide and have users rate these applications and an effective way to search for applications that are above some rating level. Apple should think harder about presenting these applications to the user in such a way that finding and evaluating gets easier. It might also want to think about the rating mechanism and how it works. Apple should spend less time in legal battles or building fences.
watty 16y ago
I disagree with (1) and (2) - why would Apple want to limit Apps? It seems to me that App #'s are one of the biggest things the iPhone has on its competitors and they don't want anyone to catch up. Android nearly doubled it's Apps accepted from February to March and I'm sure Apple are aware of it. They can already control App acceptance through their review process yet they've allowed 60+ fart apps. Also, I think there needs to be: 6.) Prevent the possibility of Adobe gaining ground with an iPhone IDE. While I think it's unlikely, Apple would be hurting if masses decided Flash was a more productive way to create the many basic Apple Apps (such as fart apps, conversion apps). 7.) Hurt the Adobe CS5 launch. Days before release, really?
- catch23 16y ago
  Have you seen the app store lately? Check out this link: http://appshopper.com/music/a003-guitartube http://appshopper.com/music/a003-guitartube Scroll down to see the other apps created by this developer. They're all cookie-cutter apps, each one for a slightly different genre of user. He has a Picasso video lounge -- for all those users who want to join the Picasso social networking video channel. I think the number of apps is pretty meaningless when you have dozens of crappy apps like this.

mrbad101 16y ago

Very very well put.

rimantas 16y ago

#5 makes a lot of sense and is often overlooked. The argument often is that it is not the tools that determine the quality, of the app, but let's see: Adobe CS5 Flash2iPhone is developed without iPhone OS 4 in sight. The main target users for it are those who are not familiar with iPhone OS and frameworks and would enjoy just pushing a button and letting the tool to do the rest. The timing is such, that a flood of apps developed this way would arrive just in time iPhone OS 4 comes out. End user does not know and does not care which tools the App was developed in. No surprise this does not look pretty in Apple's eyes. I and cannot imagine Flash2iPhone style of app producing anything about mediocre. If it targets Android too — even more so. This way all you can get is unisex, unisize sportswear. Apple wants tailor suits and designer dresses.

Tichy 16y ago
What if my app doesn't need all the latest features? I don't see how this argument makes sense. After all, competing SDKs don't force their users to stick to them. If somebody has already written a couple of Flash apps for iPhone, but now wants to program a 3d shooter, nobody is stopping him from switching to Objective-C.
- pohl 16y ago
  The needs of the many outweigh the needs of the few, or the one.
  - Tichy 16y ago
    I don't understand the logical step here, I am afraid?

mojuba 16y ago

Speaking of compatibility layers, there is one very direct consequence of being inefficient on a mobile platform: battery life. I've become somewhat sensitive to what I'm doing on my computer since I started using a laptop at home instead of a desktop computer. I usually avoid watching long videos or generally using any Flash app not only because it eats up power terribly when it works, but I may find a defunct Flash process hanging there eating up some 20% of CPU even after I close the page with Flash. The problem seems to have gone away lately, but bugs are bugs, you can't expect exceptional quality from Adobe. Neither from any other developer, especially if we are talking about cross-platform runtimes. Apple's decision starts making some sense to me now (I don't develop for iPhone, so the ongoing drama is rather distant for me). The choice of languages - C/C++/Objective-C - clearly indicates that Apple wants efficiency, not just quality. Just add one layer between the language and the CPU (e.g. a virtual machine) and your phone's battery will die 5 times faster. I'm sorry for the dynamic language folks, but we are back to the era of bits and bytes, at least when it comes to smaller mobile devices. I think smarter manufacturers of mobile devices will do something about it pretty soon, once they see the boost of quality in the iPhone market. Provided that actually happens, of course.

lispm 16y ago
That's also 'Unfug'. Flash is just bad - especially if it does not use any hardware acceleration offered by the machine for video decoding. Battery life is not much affected by a dynamic language. Because no one with a clear mind will implement things like decoding of video in a dynamic language. But what people want is to implement GAME LOGIC in another language and not in C. The real battery life that matters is based on costly processes (like flash) and using costly services. Navigation is such a thing. There are many many applications for Navigation. ALL of them are a huge source of emptying your battery. I have used a single navigation application presenting a map and recording my track - battery life goes down to two hours. The reason is the screen, the internet connection for the map and the GPS receiver - all demanding power. But people want to use those things. So in a car the iPhone gets electricity from the car. On a bike there are electricity adapters also. There is NO reason to assume that a software written in a high-level language and translated to C will empty battery five times faster. YOU CAN WRITE BATTERY EMPTYING SOFTWARE IN ANY LANGUAGE - AND SOME OF THESE APPLICATIONS ARE VERY USEFUL - LIKE NAVIGATION APPLICATIONS. Take for example a program for the iPad that plots complicated mathematical formulas. Apple forbids translating the formulas to machine code on the iPad - because that would implement another programming language and runtime on the iPad. So Apple's restriction SLOWS things down. At the same time besides computing the formula the plotting application does mostly calling UI function (drawing, 3d stuff, etc.) and waits for user interaction (zooming, rotating, ...). You can write that part in any language - it is mostly calling platform functionality. So in this domain it either don't matter (because the UI code is mostly calling to the platform) or is getting worse because of Apple's policies (because you can't compile complicated formulas on the device, because that would violate Apple's developer restrictions).

lispm 16y ago

If Apple wants to limit the total amount of applications and at the same time improve the quality, they could get rid of the literally thousands of trivial books that are each an individual application. This could be for example done by forcing them to use in-app payment for loading new books or finding another organization principle. There are relatively few conversion applications in comparison. Conversion applications are really not a problem. How about the twenty or more music sequencer applications? Currently I would not easily find out which one is really good. Should Apple limit people submitting these applications? I'd rather have the market decide and have users rate these applications and an effective way to search for applications that are above some rating level. Apple should think harder about presenting these applications to the user in such a way that finding and evaluating gets easier. It might also want to think about the rating mechanism and how it works. Apple should spend less time in legal battles or building fences.

watty 16y ago

I disagree with (1) and (2) - why would Apple want to limit Apps? It seems to me that App #'s are one of the biggest things the iPhone has on its competitors and they don't want anyone to catch up. Android nearly doubled it's Apps accepted from February to March and I'm sure Apple are aware of it. They can already control App acceptance through their review process yet they've allowed 60+ fart apps. Also, I think there needs to be: 6.) Prevent the possibility of Adobe gaining ground with an iPhone IDE. While I think it's unlikely, Apple would be hurting if masses decided Flash was a more productive way to create the many basic Apple Apps (such as fart apps, conversion apps). 7.) Hurt the Adobe CS5 launch. Days before release, really?

catch23 16y ago
Have you seen the app store lately? Check out this link: http://appshopper.com/music/a003-guitartube http://appshopper.com/music/a003-guitartube Scroll down to see the other apps created by this developer. They're all cookie-cutter apps, each one for a slightly different genre of user. He has a Picasso video lounge -- for all those users who want to join the Picasso social networking video channel. I think the number of apps is pretty meaningless when you have dozens of crappy apps like this.