Steve Jobs bans all apps from iPhone (or thereabouts) You could argue that the new Jobsian SDK bars developers from writing any application for the iPhone - unless they possess some sort of savant-like ability to think solely in Objective C. The much-discussed software development kit for the upcoming iPhone OS 4.0 says that native applications must be "originally written" in …
Apple are insignificant in comparison to Microsoft, both by turnover and market share (overall not in a specific vertical). What M$ got away with in the past, that it has now been forced to relinquish still out weighs anything apple have done or could even do.
M$ actions affected hundreds of millions of users and over a billion installed systems.
Apple can only dream of such power to abuse, and will never achieve such a market share.
I don't blame them for trying to keep control of a good (for their pockets) thing but eventually, as history has proven time and time again, the end user and the developers who make this a sucess will get fet up and move on.
Apple = Humpty dumpty before he falls of the wall. Personally, I would like to see it happen as I think iSomethings are now stifiling the market place with a false sense of superiority that is undeserved. Hopefully developers will say fcuk this and move to other platforms.
Apple are not doing anything special that can't be done elsewhere, they are vulnerable, and they know it. Hence the megalomaniac attitude.
i think both the author of this article, author of titanium, and like minded fanbois are in a deep state of denial. This sdk clause is *crystal* clear and not ambiguous as they think. Titanium? Banned. SDL? Banned. Gtk app? Banned. Scripting? Banned (if you are using it to implement your app). You can port an app but not by using ANY portability layer. Jobs could change his mind, but from what i see any ambiguity people see is all in their heads and not reality.
furthermore, i think the confidence that this won't greatly reduce iphone development is unfounded. There's better devices on the market, i could easily see an exodus of developers if apple keeps adding more and more rules.
Agreed,
The no-translation clause may have been specifically crafted by apple to exclude adobe kit, but it clearly applies to these projects as well.
On the other hand, as the author said, the clause is meaningless since apple will do whatever it pleases anyways. It may permit certain translated programs and not others. This is about opportunism rather than technical merit. If the translation software were not made public, it's doubtful that apple themselves would even know whether an app was translated or not.
The T&Cs have always had a "we will refuse your app for any reason we feel like" .. you can't get more ambiguous than that ... does not put the thousands of developers off now does it.
Apple have made this "market", if they feel they have broken it they will change their mind. So bring on the competition, only the end-user will win.
I think the titanium guy might have a valid point - as long as the apps correctly use the Apple APIs, they'll probably be OK. This is probably what the new SDK clause was really about - his argument sounds plausible/sensible anyway.
In any case how would apple be able to tell an app was written using a translator (barring any headers it might add) and not straight in Objective C or C++ etc? (OK, if the app doesn't use the APIs i suppose that might give it away...)
It's understandable that Apple want to keep the API clean and require developers to go through them. This allows Apple to implement changes to the kernel and sub-systems with less fear of breaking the hundred of thousands of existing applications.
I've developed translation software in the past, e.g. generating pure X11 toolkit API calls from a graphical IDE. I don't see that Apple terms would restrict that approach if the generated code is clean, strictly follows the API and then Xcode is used to perform the final checks and compilation. In fact, if the translation mechanism is written correctly it should be quite hard to distinguish handwritten code from translated code. So Titanium could be okay .. only time will tell if Apple are trying to future-proof iPhoneOS APIs or if they are being unnecessarily draconian.
So long as people follow the PUBLISHED API and so long as Apple don't cock up the API in a non-backwards compatible way, then existing deployed apps should be fine.
The language used to write said app is irrelevant. App asks the language to call the API, whether it is a little BASIC interpreter, standard C, or a specific Apple-sanctioned version of C-with-bells-on.
Apple is quite obviously being draconian, because the technical reason doesn't make a lot of sense. The only excuse that would work is if Apple used a shared runtime-linkable library to interface with the API, so the library can change with the API... but that's a Scary-Bad way of developing an API...
But, hey, development will only slow down by a small minority becase all the sheep know of the iPhone and the developers will put up with a lot of different s**t because it is where the money is. Some developers do it for love, the rest do it for money. iPhone = money. So long as that equation holds up, it will be a self-continuing cycle.
.
Of course, there is an implicit fail lurking. How many apps will be lesser than they should be, or buggy in ways they shouldn't, because a developer used to one way of doing things will be forced into an unfamiliar language.
never mind the new ones.
3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple's Documented APIs and built- in interpreter(s).
It's interpreting flash-like scripts.
Apple's ban translation layers could be seen as a bid for "exclusivity". If you write an app using some more widely portable framework and merely compile an iPhone version, that same app will be available for rival devices. Lots of developers prefer to work that way. If, on the other hand, Apple force you to write the iPhone version using an iPhone-only API, they're increasing the cost (to you) of maintaining both versions. You might reckon is isn't worth the cost and abandon either one of the platforms. Apple are therefore betting on more people abandoning the rivals than them. Time will tell.
I liked the title of your post because you're clearly missing the point.
"Apple's ban translation layers could be seen as a bid for "exclusivity". If you write an app using some more widely portable framework and merely compile an iPhone version, that same app will be available for rival devices. Lots of developers prefer to work that way"
You mean like writing in C?
Which is allowed...
"If, on the other hand, Apple force you to write the iPhone version using an iPhone-only API, they're increasing the cost (to you) of maintaining both versions."
Well, if you don't use the iPhone API how are you going to do anything?
The routines on Apple/Google/MS devices etc are all going to be called different things and work slightly differently, so there is no way around this at all!
Write the app as closely as you can to be within the confines of their own laws so that your app can be shown one day on itunes or the app store.
But once the program has been tested,alpha beta etc etc then crunch that program so tight and small and put it through some obfuscation program so that the apple testers can't
see the code properly as it is YOUR PROPERTY and not theirs.
If they refuse it then have a class action lawsuit against them.
How in the name of Heaven do you get from "[a]pplications must be originally written in[...]" to "originally conceived and written for the iPhone"?
Mr. Metz, you must be deliberately trolling for ad impressions; there is just no other explanation. I refuse to believe you are so think as to interpret the new clause in such a way.
As "Henry Wertz 1" mentioned above, the clause is perfectly unambiguous: if you want to write an iPhone application you must write it in one of the native languages and target the iPhone platform itself, not machine-translate it or cross-compile it from a different platform. And if using JavaScript, it must be executed by the internal WebKit engine, not a custom runtime.
-dZ.
Got it in one.
Most cross-platform development tools result in lowest-common-denominator application design. Apple are all about the UX, not the technology. What's the point of creating new UI features if developers are going to use the excuse of cross-platform compatibility to avoid using it?
Even if you develop for the desktop flavours of OS X you have to be prepared to update your apps in line with changes to APIs or your application(s) can easily fail to run properly on later OS X releases. Apple are a lot less fussed about backwards compatibility than the likes of MS and the FSF.
Apple don't *care* if the programmer has to suffer a little for his craft: it's the *customer* who rules. They're not a development tools company like Microsoft. They're sure as hell not the coder-centric FSF. If you're a programmer, you do NOT get to call the shots in the Apple ecosystem.
And you know what? This is exactly how it *should* be. And how it fucking well should have been from the start.
Design your code accordingly: separate the model *entirely* from the view and controller elements. Plan for reusability rather than focusing on mere portability. Be prepared to build new UIs for each platform, and you'll win the plaudits. Stick with merely duplicating the same UI over multiple platforms—regardless of its suitability—and you'll deserve everything you get.
And no, Objective-C isn't *that* hard. It's a blend of C and Smalltalk, not some batshit insane version of Forth.
>Apple are a lot less fussed about backwards compatibility than the likes of MS and the FSF.
Its stronger than that - iPhones and iPads are inherently life limited. Backwards compatibility is bad for business when your target consumer isn't business. Now obselete 2G owners who haven't already bought their second or third iPhone will doubtless do so soon, afterall the upgrades are 'free' aren't they?
Sad thing about PT Job's obvious low opinion of his consumers is he's probably right - only as well as one being born every minute, they also get reborn every year.
>Be prepared to build new UIs for each platform, and you'll win the plaudits.
Like Apple themselves do with Safari, iTunes and QuickTime Player on Windows? Do as I say not as I do.
Apple sucks.
"Like Apple themselves do with Safari, iTunes and QuickTime Player on Windows?"
Or like MS do with Word, Excel etc on OSX?
"Sad thing about PT Job's obvious low opinion of his consumers is he's probably right"
Apple seem to have a very high opinion of their customers and are doing their level best to make sure developers can't release crud that breaks with OS updates. Do MS have that level of care for their customers?
The fact is, Apple wrote the OS and they're saying "call our APIs in a friendly way" no sneaking your own assembler in there, just in case we change something.
Does anyone here remember what happened when developers started hitting hardware addresses on Amiga OS 1.3? Everything failed on OS 2.0. Apple obviously NEED to avoid a similar problem!
If they're so worried about changing something breaking apps (or vice versa), why have they waited so long? As far as I can tell, there's been umpteen iPhone types - and I'm forever hearing someone moan that the latest iPhone OS update crippled their jailbroken iPhone. However, I've yet to hear any big moan about a change to the OS/iPhone version breaking any app, or being broken by an app?
> why have they waited so long?
The whole thing was a big con.
They started all nice and sweet and then decided to turn into a jerk as soon as they thought they could get away with it. They wanted to sucker everyone into helping them build their mind share. Now that they have that, any particular developer is disposable to them. They view themselves as bigger than any particular developer or developers in general.
They think they've got a repeat of DOS on their hands where they think they have enough critical mass that no one can catch up to them.
What have MS got to do with this?
>Apple seem to have a very high opinion of their customers and are doing their level best to make sure developers can't release crud that breaks with OS updates.
The latest OS updates don't even support their own hardware, get a grip....
Apparently this is all about protecting Apple's customers - clearly Apple believe they lack the intelligence not to buy badly written software and will continually revisit websites with badly coded Flash content.
Thankfully Apple will protect you from these horrors - and the dangers of using your 3G connection as you might like, blacklisting callers who might have something important to say, viewing content which is political or contains bad language.....and worse of all Apps which compete with Apples own s/w offerings and might therefore confuse you with strangely desirable functionality.
This is nothing more than a written standard for a single product: NOT a single product written for many causing the many to prop it up (Flash).
"Even if you develop for the desktop flavours of OS X you have to be prepared to update your apps in line with changes to APIs or your application(s) can easily fail to run properly on later OS X releases. Apple are a lot less fussed about backwards compatibility than the likes of MS and the FSF."
This is why SJ jumped up-and-down about 12 y.o. Flash. Adobe freely admits it gives the responsibility of Flash upkeep to the platform (Linux, Apple, MS, Android, etc). If it does not run correctly, it's the platforms fault. So here, if Apple changes something in iPhone x, and your App does something strange, YOU fix it; not Apple.
"3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs ... The following non-public APIs are included in your application: u_charType ucol_close ucol_getAttribute ucol_getLocaleByType ucol_open ucol_setAttribute ucol_strcoll".
This chunk of 'quoted info' (freely available on the web) was sent to 'developer.appcelerator.com' from Apple, due to an iPhone App that was rejected about a month ago. This indicates Apple had already set the wheels in motion and it's just been discovered and revised for the iPad.
"Adobe freely admits it gives the responsibility of Flash upkeep to the platform (Linux, Apple, MS, Android, etc). If it does not run correctly, it's the platforms fault"
Which is why you can't view Flash in iPhone Safari.
Adobe's software is a flawed buggy mess and they refuse to take responsibility... if you've seen it on OSX you'd know exactly what I mean!
I suspect that Apple is having second thoughts about the direction of the app store. With the development of iPhone app creation systems and the soon to be released iPhone 4 with the new OS 4, they decided to put a stop, or at least reduce, the number of simple (and often function limited) cookie cutter apps and copies, created by these systems, which are overloading the store.
Adobe, Monotouch and Unity3d appear to be the main culprits, all either using only the simplest of iPhone API’s or cutting out the IPhone OS entirely (and Apple development environment). The problem for Apple is taking a TOS agreement, creating a rigid new rule on app development languages and applying it, when there are many companies and individuals who are now developing apps using these simplified systems. It may benefit the end user but will cause much pain to many ‘developers’.
Monotouch using the simplest of iPhone APIs ? They have just announced support for the beta 4.0 sdk which hardly sounds like simplest to me, nor does it cut out the iPhone OS entirely, it just provides a .net version of the API.
Unity is targeted towards games and provides .net support again. Simplest of iPhone APIs ? OpenGL and OpenAL are the only ones I can really think of that would be of use for games, maybe bluetooth for multiplayer. Being games you also wouldn't use all the UI APIs either. The OS would hardly be cut out though.
Adobe, can't comment on that.
since everybody & apple have their collective thongs in a wad over what should be allowed and what shouldn't, why doesn't some enterprising individual write an app that powers the iPhone off, the moment they try to use it? Think about it, it pacifies the Apple nay sayers, it get's the stick out of Jobs' ass and his overly paranoid concerns about people improperly using HIS property AND it keeps the users from doing anything that could stir up Jobs, Apple, and the anti-iPhone fanbois.
At the risk of sounding serious, I believe Mr. Jobs really needs to understand the fact that he just supplies the platform and the base OS and it's up to the consumers and developers to drive the development of the applications (outside of the standard, included applications).
Perhaps this is a sledge hammer clause to allow blocking an application that is not coded with processor cycles and memory constraints as important in the round.
Is it possible that developers of application that are most likely to be hit by this clause from the world of web and not the world of embed ?
Yes, translation produces inefficient (or flawed) code. The reasons why are simple.
1, When the APIs change, you're screwed
2, If any libraries you depend on change, you're screwed
...far better to do things the approved way.
Of course, you could write code that turns Flash into Objective-C and then compile that C. That would likely be allowed. You just can't write code that turns things into an executable binary.
This is purely a move to block platforms like .NET Compact on iPad/phone. Novell and mono nearly have .net compact working well and Apple are a bunch of scaredy cats. If .net worked on iPhone then nobody would bother using objectiveC or learning any new apple APIs. iPhones and iPads would start to look and feel like windows platforms. Personally this kind of greedy negativity is really awkward for developers and ultimatelly users will suffer. A phrase springs to mind - You know when you've been jobbied.
This is what concerns me too, my business has been developing some iPhone Apps over the last year using Unity3D with code written in C# and running on Mono ... and now we are in limbo.
What is Unity going to do? Despite their positive sentiment Apple's new TOC in iPhone OS SDK 4.0 section 3.3.1 seems perfectly clear that they are banned, and our works and investments are at risk.
Even if Apple allow Unity as and SDK with a Objective-C or C++ or C scripting rather than a platform, will be be hugely expensive for us to port all of our code from C# to Objective-C if we can?
What the fuck are you talking about?
.Net on an iPhone. Why would anyone want or need it? I for one can't be arsed learning Microsoft's new C sharp, their proprietary VB or J++.
"If .net worked on iPhone then nobody would bother using objectiveC or learning any new apple APIs. iPhones and iPads would start to look and feel like windows platforms."
Well, since my iPhone hasn't been targetted to join any bot-nets yet, I can only say that I'm VERY glad it doesn't feel like windows. Windows sucks, haven't you noticed? It's what brainless managers buy for their employees because "that's what we've always had".
"What the fuck are you talking about?" if you don't understand, why are you posting on a techie site such as this?
Here's one reason: using .Net / Mono means that one can develop cross-platform games, versus developing in Objective-C means limiting effort to Apple's products. Cross-platform development is the rational business decision for exploitation of one's work.
"...since my iPhone hasn't been targetted to join any bot-nets yet....."
What? You mean the *only* phone platform that's ever had a virus/worm/whatever circulating and spreading in numbers in the wild, despite the neverending hype of the A/V vendors for their products on all the others?
We need a FAIL and new keyboard please combined icon.
I assume the real reason for the ban is to maintain the barrier of entry.
It's relatively difficult to develop apps and yet there are already 150k apps and many/most of them are not good.
Imagine if every hack Flash "developer" could publish his rubbish "click on the carrot" game as an app... if you think the App Store is overflowing with crap now, you'd have another thing coming.
This move, while it will hurt some legitimate developers and their ability to release cross-platform titles, strikes me as fairly reasonable at this point.
Many of the top 100 apps for the iPhone were written using Unity3D.
What is annoying Jobs is the fact that Unity will soon target Android, etc..., making porting to those platforms relatively simple.
This is not about quality. It is about developer lock-in. What Mr. Jobs should keep in mind is that lock-in is also lock-out, for those game development businesses that don't like the high level of risk involved in dealing with Apple.
You are running the risk of getting on the lord jobses bad list... human?
i rather think not!
iHuman possibly, liver kidneys, lungs heart, fuck them all, steve is a magical and revolutionary being. and the mere energy of his creative geniusness can sustain him.
(plus of course only the good die young, so either way he's with us for the next couple of millenia at least)
The reason why Apple is insisting on on using their tools is the same reason they very strongly encouraged developers to switch from other compilers to XCode - to make it a snatch to move from one processor platform to another with little more than a click of a button.
If you write other programs to write your applications - ahem, Adobe and Microsoft - in spite of Apple's recommendations, then you're left with a great pig's breakfast to deal with.
This gives Apple the flexibility - and freedom from the whims of Intel, etc - to switch processors with ease without giving developers a heart attack.
I hate to break it to some of you Apple cult members but you don't need Xcode in order to support multiple processor architectures. It's quite orthogonal to the problem infact. As long as your APIs are supported on the shiny new CPU, you won't have any problems.
Arguments like these show a fundemental lack of technical understanding on the part of Apple boosters (which should not be terribly surprising really).
Tools move easily between hardware when they don't make stupid assumptions and then encode those into the guts of the system. This includes Apple's own APIs.
OTOH, the sorts of things that Apple bans most (emulators, VMs, and script languages) are actually the best at avoiding any sort of platform specific assumptions.
These sorts of excuses are hilarious to those of us that actually deal with diverse hardware and operating systems.
I had a choice between an iPhone and an Android device. I chose Android, and as time goes on I am ever more happy with my choice. If I had an iPhone, I think I'd be getting worried now whether some of apps might no longer appear on my phone, or at least would no longer have updates and improved versions available.
Is there something magic about Android that makes developers continue to support and develop their applications?
Can it be fitted to other phone OSes?
I have a few apps for Symbian and WM5/6 that I would like to get updated, but sadly the developers didn't even create bug fixes. And there are some that I had to give up completely because they didn't make a version to load on a newer firmware.
You /might/ want to take off the Android-tinted glasses every now and again.
Sure, Android has a great deal of potential, but there's nothing that makes it immune from the same old crap that goes on *everywhere* - these are problems that exist on all platforms, not just mobile ones and not just with Apple.
Android ain't immune either.
"If I have seen a little further it is by standing on the shoulders of Giants" Isaac Newton
Modern software development is about layers on layers on layers. The whole science of computing is now so large few developers have the time let alone the opportunity to learn it all. Add to that the multitude of specifications standards and software patents (may it never happen to Europe). Our job is nigh on impossible without using intermediary layers. Apples own sdk frameworks are an example of a layer and that sits on its own stack of code layers.
Steve Jobs is an example of someone who hasn't programmed in 33 years, everything is procedural when you have a single core 1mhz chip everything is simple and light weight when you have 4k of memory.
If apple push their ideas of zig heil mine fuehrer too much, then the people they need to develop for their platform will leave and migrate to the next big thing (ie. android). then the iphone becomes nothing but the vapid fashion statement for the paris hiltons of the world - with their 50,000 fart apps.
If however, apple do get a clue... which is something they've had an uncanny knack of since the gen1 iPod and rainbow coloured all in one eMac/iMac(?) got them out of trouble, then they'll just be lauded by the general media as the heralds of another new technical dawn for the general non-technocrat populace.
Either way, consumer trend moves on and the wheels of commerce keep turning. Just different companies the money goes to.
The only differentiating factor is that people seem to be getting bored with apple throwing their weight around. As soon as this starts to effect the man in the street - game over.
Plus, i don't know about you, but it seems inherent in the human condition to want to see the arrogant fall from grace.
mwahahahahaha....
'Apparently, Steve Jobs has hinted the new SDK language is an effort to prevent anyone else from establishing a de facto standard platform on top of his own tools'
what the hell.. tho if he wants to remove his shit from the technological gene pool, im not gonna stop him! natural selection taking place
They just want you to develop for Apple platform exclusively. I think the ban for these 'non native compilers' is so you can't easily make the same app run on a non apple platform. That is exactly what these tools do, they allow you to cross compile your app for non-apple platforms.
Code in objective -c, because nobody else runs that.
A reasonable guess that apple does not want cross compilation to another platform... Or wants to make it more difficult.
But this decision could (unlikely though) end up shooting steve jobs in the foot. I mean, there just may be quite a few people interested in porting stuff over to the iThingie and this may be a dealbreaker.
Having said that... Really, how many iphone apps aren't coded in some apple compatible c? I really don't know.
Right now apple is dominant for apps over any other platform (when i say 'any', for apple this means 'android' and 'symbian'). To slow down the uptake of new platforms (android) you throw up a hindrance (thou shalt not cross-compile). This forces developers to select the platform they want to develop for. Purely ecnomically speaking, as a developer, you shoot for the largest audience. And right now that is Apple. so you will put your effort where you can reap the most profit. App development for other platforms will slow down and in turn this will push down the appeal of those other platforms.
This whole thing is nothing else than a roadblock. And yes, you can argue that it would slow down uptake of new API and features, but it also blocks originality and true creativity. You will only do what i allow you to do.
>Purely ecnomically speaking, as a developer, you shoot for the largest audience. And right now that is Apple.
Apple is 25% of the handset market, 30% less if you count users rather than sales. Better business sense to focus on portable Apps across the 75% and the desktops/notebooks generally - especially since the methods developers used to create much of the current App store are now verboten.
Or perhaps you think it makes business sense to throw all that code away and start again on the same App for new T&C - rather than port it to the growing mass of alternate handsets and new customers.
Personally I think iPhone peaked in 2009, Apple's focus on iPad instead of releasing a more up to date handset - coupled with their new Stalinism, should ensure that.
Amongst all the armchair experts it is good to see someone understands the issue.
The biggest threat to iphone would be if it was commoditised as just a phone with an OS. That would give people an easy migration from one to platform to another. Objecttive C forces people to make a choice.
but also linking against their API. Now your codebase is entirely dependent on that API. And i bet money that that API is heavily protected by legalese.
These tools basically create their own API and use a translation layer. Yank that layer away and it's goodbye portability. Of course you could implement the iphone's API's on other systems but you;d be faced with legal problems but also technical problems.. And who is going to maintain what for which OS...
A couple of things:
First, i read in at least 3 places that the "approved" languages included C and C++ (oh, and a particular flavor af JavaScript). Seems that I have a **lot** of options besides Objective-C.
So I write my app in C++...and sonovabeech, I have to use one of those dreaded API thingies. Well, if I were going to want to write my app for cross-platform use, I'd write an adapter for those APIs, and when I needed to use that same functionality embodied by the Jobsian API on another platform, I'd override the adapter functions for my non-Jobs target. Yeah, it's a bit of a PITA, but then, it beats having to rewrite the entire app as you seem to suggest is the **only** way around the Steve-block. And it is complete compliance with the "law".
Maybe that is a way out. but it restricts you to what is possible with the apple API. if you use one feature not supported in that api you are stuck.
i don't know how hard that is.
Anyway the point is that it will cut off lots of app developers because their toolchains have been invalidated.
I agree with a lot of the post-ers on here. If this was Microsoft, the lawyers and courtrooms of the world woul dbe rattling there sabres. Why has no one legally challenged Apple about these ridiculous rules they keep setting??!!
It's bad enough that we have to use Safari on the iPhone, at least we can use Opera now, but Apple will still find ways to ban browsers like Firefox, and banning other apps just because they have words like Pad of use the "i" in there names is pure lunacy!!
In a world MONOPOLY.
Microsoft was judged (in courts in the USA and around the world) to have a monopoly position in the personal computer market. Do you see? They were saying that there was no reasonable alternative to using Microsoft products and this could be used by Microsoft as a lever in other markets and as a bargaining tool in lobbying for legislation. Do you see how that might effect the rules on what they should be allowed to do? Do you see that it would not be in any country's best interest or in the interests of any business or individual to have a commercial enterprise with that much power over business and state? Especially one that has been convicted (in courts in the USA and around the world) of underhanded and often illegal practices. Do you see how that puts Microsoft in a different position to other companies?
At the time of the famous court rulings if the user didn't like what Microsoft did then they could not reasonably move to another platform. That may or may not still be the position Conversely if you don't like what Apple says about the iPhone you can easily use a different smartphone and get a similar service. Loads of people don't like Apple and don't buy/use their products with minimal effects to their lives or businesses (I know some of the more rabid Apple fans may disagree). Do you f***king see now?
"and banning other apps just because they have words like Pad of use the "i" in there names is pure lunacy!!"
Takuhii,
you obviously did not studied laws or worked in a marketing department. If i paid good money to register and/or use names such as Pad an iWhatever in my products i surely wants to keep the privilege for my own products especially if i control the market place.
In a more practical way, as a user, if you see a iWhatever you'd think the product is related to Apple and blame them if it fails.
There is no lunacy here. Just a company protecting his products.
It's pretty clear that Apple's concern is keeping control over the APIs that developers use for their platform. If some other compatibility library (from Adobe or anyone else) becomes the defacto standard way of writing iPhone/iPad apps then Apple is pretty quickly at the mercy of that vendor and whatever APIs and platforms they choose to support. Apps will be coded to the lowest common denominator, and any fancy new features or new platforms that Apple tries to introduce to distinguish itself from other mobile platforms will be irrelevant as most apps won't support them.
That concern is understandable from Apple's point of view, but as a developer it sucks. I don't want Apple telling me how I should write my apps, still less implicitly telling me I can't also write them for other platforms. So, I wish Adobe every success with their lawsuit.
Suppose (Adobe/whoever) refuse to add support for your shiny new API/hardware unless you pay them to do it?
And what about all the work you put in trying to make the UI slick and fast. Add in a one-size-fits-all translation later and you risk ending up with something that runs like a three legged dog with asthma. Who will your end users blame? Probably not the developer or the tool writer.
I've said this before, people are looking at the iPhone/iPad/iPod platform the wrong way, it's *not* a general computing platform, it's more akin to a game console platform from a few years ago - the console manufacturer tightly controlled a good chunk of the development/release cycle; some of them did their own play testing and some of them even branded all of the titles.
Sure, that market has loosened up a bit in the last few years, but you still can't just decide to be an Xbox programmer and sit down in your back room to do it, there are hoops to jump through and contracts to sign first.
I'm not saying it's right, just saying that's the way it is. Some developers will decide that's it's not worth the effort and move on, some won't. I'm pretty sure that enough will stay to develop for those 85 million devices to keep the platform viable for a while yet, though.
Heil Steve Jobs!
Heil Steve Jobs!
Heil Steve Jobs!
crApple again show why they shouldn't be trusted and how they are clawing tooth and nail to corner the market and monopolize while they can. There is no element whatsoever in the crApple ethic that is about the customer, it's all about getting iSheep to only use crApple for everything so they can milk them dry.
You poor fools.
Yes for open soruce, yes for open platforms, yes for less restrictive SDK's that promote incusion and creativity, yes for making it about technology and the customer and not lining a medioca-tech company's pocket.
I really don't think I need to say any more....... farking megalomaniac.
are just all kinds of fail. It's not as if Obective C/C/C++ are hard languages to grasp especially if you call yourself developers. Get a grip. I'd much rather use natively written applications (on any platform) as they are simply much more polished and better optimised. It's obvious (and fact).
Cross-compiled software is bollocks, as are the cross compilers. Stop being so f*cking lazy and write your applications properly.
I can see why they want to put up roadblocks for people trying to create multi-platform applications, as long as the other target platforms are symbian/android/blackberryOS. But what if you're trying to develop an application that can run on different versions of iPhoneOS? When OS4 is released this summer there will be three versions available at the same time: 3.1 for 1st gen iPhone/iPodTouch, 3.2 for iPad and 4.0 for newish iPhones.
The most reasonable way to manage this would be using some kind of wrapper that emulates the missing new APIs for 3.x hardware (or does Jobs not want people to develop for the iPad?)
This has not happened to me as of yet but if and when it does I will vote with my money, could mobile operators be implicated?
I am hearing stories of people in the EU receiving money from retailers over the removal of features on the PS3 could this same legislation not be used for removal of paid apps on the Iphone?
It depends on whether the developers have stuck to Apples rules and the offical APIs. If developers stick to Apples new rules you can guarantee that your apps will work with newer versions of the OS. If the developers (such as Adobe) bypass the official APIs there's a good chance the apps won't work with newer versions as the workarounds they use might not still be there.
Been down that road with Adobe in the past - update to a newer Mac OSX version and you have to upgrade to a new version or wait for a patch for Photoshop and Dreamweaver as your old versions no longer work. If Adobe stuck to official Apple APIs the software would still work and not need hacks by Adobe to stop them crashing.
Strangely enough my old version of Office still manages to work fine.
for more than one mobile platform
and the iPhone is one platform you are targetting
and Jobs persists with this restrictive and monopolistic approach
then
write a layer that translates between the iPhone API and the other platforms you wish to support
yes, you are playing by Job's rules but you are thwarting his attempt to lock-in developers
you can code in C/C++ so you are not constrained by the possible lack of an ObjectiveC compiler for your alternative platforms
....iDon't give a fuck about anything they do, I've lived a long and happy existence without ever owning a single piece of shiny apple crap.
Why on earth would anyone spend the money on things like iPods which tie you into buying more shit from apple is beyond me. I would rather buy a regular MP3 player for half (or less) the money, and be able to use any MP3s I like on it. Some people obviously like spending money on crap. Shiny crap, but still crap.
Dear Adobe,
Since Apple love your products so much, I suggest that you make your next version of the Creative Suite, Acrobat Reader (and all of the other myriad of programs that you've bought) only for the Windows platform, or even for Linux if you're feeling daring.
Apple doesn't need Adobe. Apple doesn't need anyone.
I don't think anyone can really dispute that the iPhone platform (and there for development for it) is Apple's ball and they can damn well take it home anytime they like. Those that bang on about rights and freedoms that Apple "owes" them are generally children and the deluded.
However much like the actual balls the saying comes from - if you "take it home" too often then sooner or later you run out of people that want to play with you.
iPhone app development is a good way of making some money right now - the market is strong and barriers to entry are not insurtmountable. Anyone who relies on it totally is an idiot though, Apple can (and has shown that it will) move the goalposts at a drop of a hat so it's no good these people throwing their arms up in the air in shock and horror when they do. To paraphrase a certain popular show involving unfeasibly hot robots "All of this has happened before and all of this will happen again"
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
