or Connect
AppleInsider › Forums › Mobile › iPhone › Apple's prohibition of Flash-built apps in iPhone 4.0 related to multitasking
New Posts  All Forums:Forum Nav:

Apple's prohibition of Flash-built apps in iPhone 4.0 related to multitasking

post #1 of 171
Thread Starter 
Apple's new iPhone 4.0 SDK license now blocks cross-compiled third party apps, such as those built from Flash CS5. Rather than being just a competitive blow directed at Adobe however, it appears the real motivation is to support sophisticated new multitasking features in the new operating system.

Reports of the change in Apple's 4.0 license trickled in from a variety of sources, many of them either glad Apple was taking a tough new stance against "Flash shovelware" or alternatively upset that the company was limiting developers to its own development tools and languages.

But if Apple were simply trying to block Adobe from cross-compiling Flash to create iPhone apps, it could have added the changed text to its existing license agreement and spoiled Adobe's CS5 party immediately, rather than just threatening change that appears fated to kick in when Apple delivers iPhone 4.0 in June.

The primary reason for the change, say sources familiar with Apple's plans, is to support sophisticated new multitasking APIs in iPhone 4.0. The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this if apps are running within a runtime or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app.

"[The operating system] can't swap out resources, it can't pause some threads while allowing others to run, it can't selectively notify, etc. Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS," wrote one reader under the name Ktappe.

Multitasking in iPhone 4.0

Apple debuted a series of seven multitasking APIs to enable developers to optimize their apps to run on the new iPhone 4.0, only taking advantage of the resources they actually need.

For example, Fast Switching allows running apps to be effectively frozen in the background so that they don't consume any extra overhead at all. If the user is playing a game and switches to a phone call, there's no need for the game to actually continue playing in the background, and this would usually be undesirable anyway.

On the other hand, Apple also demonstrated APIs that enable background apps to keep working on a necessary job under the name Task Completion. This enables apps that truly need to finish working to do so without making that the default behavior for all apps on the system.

Other new services, such as Background Audio, Voice over IP and Background Location, enable apps to take advantage of special APIs to deliver a particular service they want to offer in the background, leveraging operating system support to do so as efficiently as possible.

Push Notifications and Local Notifications allow apps to go to sleep and leave the operating system on the hook for listening for updates or setting reminders.



Multitasking on other platforms

Other platforms have enabled multitasking by simply allowing any number of apps to run. This results in a mess for users because it's up to them to manage which apps are running out of control or needlessly chewing up resources in the background. Android and Windows Mobile are both notorious for needing TasKiller or some other sort of manual process manager to keep battery life and performance in check.

Microsoft's solution to the mess on Windows Mobile was to start over with Windows Phone 7 this winter, which removes multitasking and attempts to save state for each app it puts on hold. But Microsoft hasn't outlined how it plans to deliver the multitasking features users will expect on its new platform in the way Apple demonstrated for iPhone 4.0 this summer.

Additionally, that fact that Apple introduced its Push Notifications service first means that most iPhone apps are already designed to respond to outside events efficiently. On the BlackBerry OS, for example, apps that run in the background often inefficiently poll their servers, a big tax on battery life. This is somewhat ironic because Blackberry is renowned for running its own push services, it just didn't open these to developers until third party software had largely already rolled their own solutions.
post #2 of 171
I am very excited for the new OS. Apple seems to have nailed it again and I can't wait for it to be out in full force. I think its going to be well worth the wait.
post #3 of 171
Aha ... So when people were bitching that iPhone OS didn't have multitasking they meant to say that it didn't have A shitty, poorly implemented, battery draining form of multitasking.

Huh. I guess Apple may be late to the game, but the best player nonetheless.
post #4 of 171
Per Bloomberg:

To the extent new releases of operating systems or other third-party products, platforms or devices, such as the Apple iPhone or iPad, make it more difficult for our products to perform, and our customers are persuaded to use alternative technologies, our business could be harmed, Adobe said today in the filing with the U.S. Securities and Exchange Commission under a risk factors heading.

I guess Steve has their attention.
na na na na na...
Reply
na na na na na...
Reply
post #5 of 171
At least Flash developers were warned before they shelled out the benjamins on a CS5 upgrade next Monday.

   Apple develops an improved programming language.  Google copied Java.  Everything you need to know, right there.

 

    AT&T believes their LTE coverage is adequate

Reply

   Apple develops an improved programming language.  Google copied Java.  Everything you need to know, right there.

 

    AT&T believes their LTE coverage is adequate

Reply
post #6 of 171
Quote:
Originally Posted by Eriamjh View Post

Aha ... So when people were bitching that iPhone OS didn't have multitasking they meant to say that it didn't have A shitty, poorly implemented, battery draining form of multitasking.

Huh. I guess Apple may be late to the game, but the best player nonetheless.

Agreed, better wait till you get something right. The new 4.0 looks awesome. Can't wait for the same abilities on iPad too. I was surprised Steve didn't mention that the iPad would also receive the same new features soon. I have to assume it will though.
Been using Apple since Apple ][ - Long on AAPL so biased
nMac Pro 6 Core, MacBookPro i7, MacBookPro i5, iPhones 5 and 5s, iPad Air, 2013 Mac mini, SE30, IIFx, Towers; G4 & G3.
Reply
Been using Apple since Apple ][ - Long on AAPL so biased
nMac Pro 6 Core, MacBookPro i7, MacBookPro i5, iPhones 5 and 5s, iPad Air, 2013 Mac mini, SE30, IIFx, Towers; G4 & G3.
Reply
post #7 of 171
Quote:
Originally Posted by John.B View Post

At least Flash developers were warned before they shelled out the benjamins on a CS5 upgrade next Monday.

OMG that's a good point - this news will stop a hell of a lot of people upgrading if that was their interest and I suspect it was certainly right up there among the reasons to upgrade (although the new PS looks fun).
Been using Apple since Apple ][ - Long on AAPL so biased
nMac Pro 6 Core, MacBookPro i7, MacBookPro i5, iPhones 5 and 5s, iPad Air, 2013 Mac mini, SE30, IIFx, Towers; G4 & G3.
Reply
Been using Apple since Apple ][ - Long on AAPL so biased
nMac Pro 6 Core, MacBookPro i7, MacBookPro i5, iPhones 5 and 5s, iPad Air, 2013 Mac mini, SE30, IIFx, Towers; G4 & G3.
Reply
post #8 of 171
Speaking as a developer, I'd like to say that I suspect this AI entire article is almost entirely false. If there was a technical limitation Apple could simply state that limitation, not ban all similar technology outright. Games made with Unity3D, business Java apps compiled with gcj, etc., operate at a low level just like native apps.

It's a business decision, not a technical one.
post #9 of 171
Sometimes patience is important before jumping to conclusions.

Especially since I just came from reading outlandish comments in the "Adobe Acknowledges That Apple's Flash Prohibition Could Harm Business" thread.

Check this out too:
http://theflashblog.com/

Now I am not saying that Apple may not have other motives or this is the only reason but this sounds like a good reason to me why Apple is limiting the language being used.

It will come out in the wash if this reason is legit or not. However all these "silly" comments I bet will offer very little apologies if any if this reason turns out to be legit.
post #10 of 171
Makes sense, but to be fair they really should make a version of iPhone Xcode for Windows. Apple is all too happy to sell Windows users a phone and an iPad, but then not allow them to program for it without buying a Mac. Windows is where Flash CS5 was going to take off with the iPhone export feature. Oh well I shouldn't worry about Windows people, they have much bigger problems than no Xcode.

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
post #11 of 171
This makes sense. My initial impression was that this was just Apple acting petty, but I just watched the video and there are clearly a lot of new APIs that could not be used in Flash. The new multitasking implementation is absolutely brilliant, far above anything I was expecting. That goes for most of the new OS. The only thing I was hoping for that was not included was some sort of limited folder access for Documents, Downloads, etc. This is more relevant for the iPad which I don't anticipate getting for the time being (when rev2 and a few killer music apps come along it will likely be a different story).
post #12 of 171
Quote:
Originally Posted by digitalclips View Post

OMG that's a good point - this news will stop a hell of a lot of people upgrading if that was their interest and I suspect it was certainly right up there among the reasons to upgrade (although the new PS looks fun).

In the interests of disclosure, I'll be first in line to buy the new 64-bit Photoshop CS5 (as well as Lightroom 3 as soon as the upgrade ships).

   Apple develops an improved programming language.  Google copied Java.  Everything you need to know, right there.

 

    AT&T believes their LTE coverage is adequate

Reply

   Apple develops an improved programming language.  Google copied Java.  Everything you need to know, right there.

 

    AT&T believes their LTE coverage is adequate

Reply
post #13 of 171
Another question is in light of this new requirement for multitasking, do all of the current Apps need to be upgraded to the new version and do all Apps submitted have to be 4.0 or can people still use their current SDK and choose not to upgrade.

Also can someone explain how you quit an App in multitasking environment? I'm sure it has been explained somewhere but I have not seen it yet.

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
post #14 of 171
Quote:
Originally Posted by AppleInsider View Post

The primary reason for the change, say sources familiar with Apple's plans, is to support sophisticated new multitasking APIs in iPhone 4.0. The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this if apps are running within a runtime or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app.

Am I the only one who doesn't buy this explanation? Sure, if I wanted to take advantage of the new multi-tasking capabilities I have to use the supported languages because how else would I be able to access those APIs? But if I don't care about that why again does my code have to be written in an approved language?

I agree with poster above. There is absolutely no technical reason for the ban of code not written in an approved language.
post #15 of 171
maybe there could a flag for apps to op-out of multitasking.
post #16 of 171
Quote:
Originally Posted by Booga View Post

Speaking as a developer, I'd like to say that I suspect this AI entire article is almost entirely false. If there was a technical limitation Apple could simply state that limitation, not ban all similar technology outright. Games made with Unity3D, business Java apps compiled with gcj, etc., operate at a low level just like native apps.

It's a business decision, not a technical one.

Come on!

Daniel Eran Dilger (aka: prince@appleinsider.com) is the author and you are surprised? that the article seems slanted?

How long have you been around?

   Apple develops an improved programming language.  Google copied Java.  Everything you need to know, right there.

 

    AT&T believes their LTE coverage is adequate

Reply

   Apple develops an improved programming language.  Google copied Java.  Everything you need to know, right there.

 

    AT&T believes their LTE coverage is adequate

Reply
post #17 of 171
Quote:
Originally Posted by cynhgm View Post

Am I the only one who doesn't buy this explanation? Sure, if I wanted to take advantage of the new multi-tasking capabilities I have to use the supported languages because how else would I be able to access those APIs? But if I don't care about that why again does my code have to be written in an approved language?

I agree with poster above. There is absolutely no technical reason for the ban of code not written in an approved language.

because then your process will be blocking other process if the iPhone OS can't properly put your process to sleep.
post #18 of 171
Quote:
Originally Posted by mstone View Post

Makes sense, but to be fair they really should make a version of iPhone Xcode for Windows. Apple is all too happy to sell Windows users a phone and an iPad, but then not allow them to program for it without buying a Mac. Windows is where Flash CS5 was going to take off with the iPhone export feature.

Then where is Visual Studio for Mac OSX?

Quote:
Originally Posted by mstone View Post

Oh well I shouldn't worry about Windows people, they have much bigger problems than no Xcode.

   Apple develops an improved programming language.  Google copied Java.  Everything you need to know, right there.

 

    AT&T believes their LTE coverage is adequate

Reply

   Apple develops an improved programming language.  Google copied Java.  Everything you need to know, right there.

 

    AT&T believes their LTE coverage is adequate

Reply
post #19 of 171
This article makes zero sense: there is no reason that Adobe couldn't update it's flash->iPhone compiler to support the new multi-tasking APIs.

Apple wants applications that have been tailored directly for their platforms... they don't want generic applications that "work" on platforms. So they'll create whatever rules they need to ensure that this happens.
post #20 of 171
Quote:
Originally Posted by cynhgm View Post

Am I the only one who doesn't buy this explanation? Sure, if I wanted to take advantage of the new multi-tasking capabilities I have to use the supported languages because how else would I be able to access those APIs? But if I don't care about that why again does my code have to be written in an approved language?

I agree with poster above. There is absolutely no technical reason for the ban of code not written in an approved language.

I'm not sure I exactly buy the explanation either, which seems to be based entirely on the comments of, "one reader under the name Ktappe."

However, a whole class of apps that, as you say, don't care about implementing multitasking capabilities and don't actually have access to the APIs seems like exactly one of the reasons why Apple would do this.
post #21 of 171
Quote:
Originally Posted by Booga View Post

Speaking as a developer, I'd like to say that I suspect this AI entire article is almost entirely false. If there was a technical limitation Apple could simply state that limitation, not ban all similar technology outright. Games made with Unity3D, business Java apps compiled with gcj, etc., operate at a low level just like native apps.

It's a business decision, not a technical one.

I’m suspicious too. I don’t know who these mysterious sources are, so what they say has no track record.

If it IS true, then I really hope Apple and Unity can work something out, because a lot of great games will vanish without that kind of middleware! My (not yet released) iPhone/iPad game uses physics and lighting and Unity provides. Without Unity, it will not be released. I can’t afford to hire a team to re-invent what Unity already does so well. (Not that I can even afford all the time and money I have already spent on the game. But it’s a fraction of what it would take without Unity.)

As for Flash, well—that may turn out to be more clear-cut. They bypass Xcode, for instance. Just don’t take down great tools like Unity in the process, and financially ruin some of the creative indie game developers who have helped make the iPhone platform so great! Developers who have always played by the rules—until yesterday the rules changed without warning!
post #22 of 171
Quote:
Originally Posted by Booga View Post

Speaking as a developer, I'd like to say that I suspect this AI entire article is almost entirely false. If there was a technical limitation Apple could simply state that limitation, not ban all similar technology outright. Games made with Unity3D, business Java apps compiled with gcj, etc., operate at a low level just like native apps.

It's a business decision, not a technical one.

So if you "suspect it is false," what's your explanation as to why Apple didn't add the restriction to the existing SDK and churn it out today? If disrupting Adobe was just a business goal, why attach it to iPhone 4.0 and delay things until June?

Or are you just a troll? Perhaps as a "developer," you can elucidate your position and explain something, rather than just making blanket, and irrelevant comments. It appears to have nothing to do with the "low level" at which apps supposedly operate, considering that apps all run in a fairly high level sandbox. Or do you "suspect," as a "developer" that iPhone apps run on the bare metal?
post #23 of 171
Quote:
Originally Posted by ihxo View Post

because then your process will be blocking other process if the iPhone OS can't properly put your process to sleep.

I'm a developer and this is not entirely true. If the OS can't put your process to sleep properly only your process gets harmed. Once it gets awaken its processing could have been jeopardized. There could be logic problems with other processes if your process shares resources with them but that is an issue with the logic, algorithm in your program and not with the process per se or the way it was coded with whichever tools.

Apple will have to provide better (technical) reasons than the ones already presented. So far it seems to be solely a business decision.
post #24 of 171
Does anyone else see the striking similarities of this "multitasking" and what MS announced WP7 would have?
post #25 of 171
This argument about why all languages except C/Objective-C/C++ are prohibited doesn't hold up at all. All developers submit to the App Store is a binary--no source code at all. So if Apple is analyzing the program some how, they are analyzing the binary. And any natively compiled language would look the same to such a tool.

Remember, Apple isn't just banning interpreted code anymore, they're banning statically compiled code just because it comes from a different source language. This targets way more than just Flash, including hundreds of decent apps already in the App Store. Just because a different programming language is used doesn't mean it's a crappy port, and it doesn't mean it uses crappy shim libraries. Many apps are written exclusively for the iPhone using only Apple's APIs, but are written in other more productive programming languages.

Objective-C is a good language. But it is old and relatively slow. There is 30 years of computer science research built on the lessons learned with the C family of languages. You can compile and link modern languages like Scala natively, no shims, no interpreted code. The executables are nearly indistinguishable from compiled C code--and they run even faster than ObjC. But they are banned now because they're not on Apple's narrow list.

Computer science progress is being collaterally murdered in Apple's attempt to thwart Adobe. This won't scare too many developer's away from Apple's platform. But it will stop new, sophisticated software from appearing on it. Ironically, if you want to write a complex app specifically targeting the iPad, rather than porting a crappy existing app, your best bet is to use a modern language in which you are a 100x more productive. For a complex, innovative project, most developers simply don't have the resources to do it in C*--even if they know how to perfectly well.

I am in this boat. I know C/Objective-C/C++ damn well. They are each good languages in their own way. But my team and I can't possibly complete the ambitious plans we have in those languages starting from scratch in an acceptable timeframe. And again, what is driving me off the wall, is the end result using our language of choice would be faster, more stable, more maintainable, just as native, and with no bloated intermediate layers. I'm all for keeping Flash and crappy port ware off of the App Store. But these rules do so much more than that. Apple is shooting themselves in the foot (and me in the head).
post #26 of 171
Quote:
Originally Posted by Glockpop View Post

So if you "suspect it is false," what's your explanation as to why Apple didn't add the restriction to the existing SDK and churn it out today? If disrupting Adobe was just a business goal, why attach it to iPhone 4.0 and delay things until June?

Or are you just a troll? Perhaps as a "developer," you can elucidate your position and explain something, rather than just making blanket, and irrelevant comments. It appears to have nothing to do with the "low level" at which apps supposedly operate, considering that apps all run in a fairly high level sandbox. Or do you "suspect," as a "developer" that iPhone apps run on the bare metal?

Heh, someone's a troll here but it's not me.

You have to sign the new developer agreement in order to download the 4.0 SDK. For me, it's already in place since I downloaded the 4.0 SDK. Apple didn't wait. The agreement I clicked on did not state that it would only go into effect after the 4.0 SDK is released.

And yes, iPhone apps run pretty close to the bare metal. They have to in order to get performance out of the device. UIKit is a nice abstraction and Core Animation is nice for basic visual effects, but if you enjoy playing games on your iPhone you're using an app that was written to the OpenGL spec and uses all sorts of compiler, math library, and coding tricks to eek out performance.

There are still tookits like Cocos2D and OolongEngine that are "native" to the iPhone, but a lot of the toolkits that developers were planning on to get some really good apps over are now no longer available. And I suspect that will mean that iPhones will start falling behind the curve, with the best new apps and games available elsewhere first and the ports available on the iPhone months later, just like what happened to the Mac 10 years ago.
post #27 of 171
Quote:
Originally Posted by John.B View Post

Then where is Visual Studio for Mac OSX?

That all stems from either MS not writing the .net framework for OSX, or Apple simply not allowing it. I find it interesting that you can create programs for OSX in VS on a Windows machine though, so if you ran parallels, you could write apps for osx in VS, on a mac.
post #28 of 171
Quote:
Originally Posted by cynhgm View Post

Am I the only one who doesn't buy this explanation? Sure, if I wanted to take advantage of the new multi-tasking capabilities I have to use the supported languages because how else would I be able to access those APIs? But if I don't care about that why again does my code have to be written in an approved language?

I agree with poster above. There is absolutely no technical reason for the ban of code not written in an approved language.

I think we need to know more about how the Adobe tool works. If there is some kind of "runtime" bundled with every Adobe generated app then I could see it being a problem. On the other hand, if the generated app is able to respond to the same messages that "normal" Objective C apps respond to, then the app should be fine. Adobe could probably solve the license issue if they make their tool generate an Xcode project with ObjC source code that contains all the required boiler plate event handlers.
post #29 of 171
Quote:
Originally Posted by mstone View Post

Another question is in light of this new requirement for multitasking, do all of the current Apps need to be upgraded to the new version and do all Apps submitted have to be 4.0 or can people still use their current SDK and choose not to upgrade.

Also can someone explain how you quit an App in multitasking environment? I'm sure it has been explained somewhere but I have not seen it yet.

Double tap the home button to bring up the background process tray, then hold on an app until a - sign appears over it. Tap that and the app quits
post #30 of 171
Quote:
Originally Posted by Glockpop View Post

So if you "suspect it is false," what's your explanation as to why Apple didn't add the restriction to the existing SDK and churn it out today? If disrupting Adobe was just a business goal, why attach it to iPhone 4.0 and delay things until June?

It seems from here as though Adobe will soon be releasing an kind of Flash interpreter (they call it a "compiler" but I'm unconvinced) despite the ban on them in previous SDK agreements.

And Apple seems to have preemptively clarified the matter before Flash CS5 ships (on Monday). Until then there technically isn't a released version, just the beta.

   Apple develops an improved programming language.  Google copied Java.  Everything you need to know, right there.

 

    AT&T believes their LTE coverage is adequate

Reply

   Apple develops an improved programming language.  Google copied Java.  Everything you need to know, right there.

 

    AT&T believes their LTE coverage is adequate

Reply
post #31 of 171
Quote:
Originally Posted by nagromme View Post

If it IS true, then I really hope Apple and Unity can work something out, because a lot of great games will vanish without that kind of middleware!

I don't use Unity, but I suspect the core is probably in C or maybe even in obj-C for the iphone. What you wrote in C# or Javascript or whatever it is are being translated into obj-C calls by the engine. and you project is compilable on xCode, it should be fine.

People might think this is targeting Adobe, but in reality this might be written specifically for Opera. Opera says their rendering engine doesn't execute code, it's interpreting their proprietary markup language. That takes them out of the equation.
post #32 of 171
Quote:
Originally Posted by TroubleStarter View Post

I'm a developer and this is not entirely true. If the OS can't put your process to sleep properly only your process gets harmed. Once it gets awaken its processing could have been jeopardized. There could be logic problems with other processes if your process shares resources with them but that is an issue with the logic, algorithm in your program and not with the process per se or the way it was coded with whichever tools.

Apple will have to provide better (technical) reasons than the ones already presented. So far it seems to be solely a business decision.

Could we have a moratorium on people starting their posts with "I'm a developer and ..." We have no way of checking and some self-identified "developers" on this forum seem to be clued out on some of the most basic elements of the OS and how it works.

In your case, you seem to be arguing against your own point, or at least arguing on both sides of it at the same time. You say that the idea of the systems inability to shut down processes correctly if not made with the prescribed tools is "not entirely true," but then you do on to describe how it is kind of true anyway. If the system can't reliably shut down a process and then re-awaken it in the same state, that's already a huge problem whether it affects other running processes or not. Then you describe a way in which other running processes could be affected anyway.

I don't see the point of making this argument at all when it's pretty clear that any of these unexpected outcomes would be disastrous and create an awful end-user experience.

The reality is that the decision to do this is most likely a business decision *and* a quality decision. These are both things that Apple cares rather deeply about. if the easiest way to solve all these problems is just to say "no mickey-mouse tools allowed," then Apple's decision makes total sense to me. I can't think of a single good argument why Apple *shouldn't* disallow such things.
post #33 of 171
Quote:
Originally Posted by TroubleStarter View Post

Apple will have to provide better (technical) reasons than the ones already presented. So far it seems to be solely a business decision.

You act as if it is a technical reason it is forgivable, but if it is a business decision then it is unrighteous. Some people seem to look for evil in everything a corporation does. As for me I will give Apple the benefit of the doubt that they have a reason that makes sense to them, whether technical or business.

I have not seen an official Apple explanation, but I have seen a lot of rampant speculation.
post #34 of 171
Quote:
Originally Posted by Eriamjh View Post

Aha ... So when people were bitching that iPhone OS didn't have multitasking they meant to say that it didn't have A shitty, poorly implemented, battery draining form of multitasking.

Huh. I guess Apple may be late to the game, but the best player nonetheless.

One of the things that has made the iPhone have high retention rates has been the unbeleivable stability & performance. My BBerry was a piece of garbage & 3rd party apps were always crashing the whole system. There is a reason they need a removable battery, you have to pull it out like once a week!!!

Apple is an expert at making products that do what they are advertised to do & do it beautifully. Microsoft & other are experts at making devices that supposedly do everything & then do everything horribly. I'd rather things just work so I don't waste half my life on garbage that doesn't perform as advertised.

In this regard I think OS X really has some way to go. It has come far & Snow Leopard has been by far the most stable OS for me but I would like to see them take 10.7 more in a direction like the iPad & iPhone. Switching from PCs to Macs was one of the greatest life decisions I ever made & not once in the past 5 years have I regretted it.
post #35 of 171
Quote:
Originally Posted by amitofu View Post

This argument about why all languages except C/Objective-C/C++ are prohibited doesn't hold up at all. All developers submit to the App Store is a binary--no source code at all. So if Apple is analyzing the program some how, they are analyzing the binary. And any natively compiled language would look the same to such a tool.

I'm not an iPhone OS developer, but, if the structure of apps on iPhone OS is like the structure of apps on Mac OS X, this isn't really true. There's the compiled code, and then there are various, separate resource files that make up the .app, not all of which are in binary format.

Quote:
But my team and I can't possibly complete the ambitious plans we have in those languages starting from scratch in an acceptable timeframe.

This may be the case, at least temporarily, but, in the long-run, developers, the platform and users are likely to benefit more from 3rd-party frameworks developed in Objective-C, with Objective-C interfaces, and supporting Objective-C techniques, than from tools that go off in a completely different direction and don't actually add value to the platform.
post #36 of 171
Quote:
Originally Posted by Booga View Post

Heh, someone's a troll here but it's not me.... I suspect that will mean that iPhones will start falling behind the curve, with the best new apps and games available elsewhere first and the ports available on the iPhone months later, just like what happened to the Mac 10 years ago.

I think you lost all credibility (and your status as possibly a non-trolling type), with this statement.

It's just absolute fantasy IMO and no serious developer who knew much about the current landscape would support it. Consider the following:
  • XCode is extremely easy to use and free.
  • Apple also allows pretty much any serious competitors' tools on any other platform by allowing C, and C++ as well as Obj. C.
  • The iPhone platform (85 million devices and counting!), is by far the biggest, the most vital, and the most profitable market to code for.
The idea that there is some group of serious developers, that have no talent with these popular tools but somehow have great talents with lesser tools is a joke. The idea that there is a group of developers so pissed off at Apple for doing this, that they are going to code stuff for Android first out of spite, (ignoring the giant iPhone device market), is similarly ludicrous. Finally, the idea that even if those two things were true, that these people would also only use tools that wouldn't allow their product to be easily ported (or in fact simultaneously developed for), the iPhone is also pretty silly.

In short, your analogy is completely unrealistic.
post #37 of 171
Quote:
Originally Posted by Prof. Peabody View Post

Could we have a moratorium on people starting their posts with "I'm a developer and ..." We have no way of checking and some self-identified "developers" on this forum seem to be clued out on some of the most basic elements of the OS and how it works.

In your case, you seem to be arguing against your own point, or at least arguing on both sides of it at the same time. You say that the idea of the systems inability to shut down processes correctly if not made with the prescribed tools is "not entirely true," but then you do on to describe how it is kind of true anyway. If the system can't reliably shut down a process and then re-awaken it in the same state, that's already a huge problem whether it affects other running processes or not. Then you describe a way in which other running processes could be affected anyway.

I don't see the point of making this argument at all when it's pretty clear that any of these unexpected outcomes would be disastrous and create an awful end-user experience.

The reality is that the decision to do this is most likely a business decision *and* a quality decision. These are both things that Apple cares rather deeply about. if the easiest way to solve all these problems is just to say "no mickey-mouse tools allowed," then Apple's decision makes total sense to me. I can't think of a single good argument why Apple *shouldn't* disallow such things.

Although I'm not the original poster, let me just say that (as a developer!) this sort of thing isn't rocket science. To suspend an app, just write all of its allocated writeable RAM out to NVRAM, save the processor registers, and stop giving it time. To wake it back up, restore the RAM and the registers and give it cycles. It doesn't matter if it's interpreted, compiled with an alternate compiler, or a "true" Objective C app.

Yes, I have a couple apps on the store and wrote the first one using UIKit and Core Animation because nothing else existed yet. I actually haven't released anything using Unity or one of the other dozen toolkits that are popping up, but I was hoping to.

But I had also been planning on recommending such a path at work to get our Java and C# libraries over to the iPhone for some Enterprise-level stuff. Now that's never going to happen. Looks like we'll be sticking with .NET 4.0 there.
post #38 of 171
Quote:
Originally Posted by Prof. Peabody View Post

Could we have a moratorium on people starting their posts with "I'm a developer and ..." We have no way of checking and some self-identified "developers" on this forum seem to be clued out on some of the most basic elements of the OS and how it works.

In your case, you seem to be arguing against your own point, or at least arguing on both sides of it at the same time. You say that the idea of the systems inability to shut down processes correctly if not made with the prescribed tools is "not entirely true," but then you do on to describe how it is kind of true anyway. If the system can't reliably shut down a process and then re-awaken it in the same state, that's already a huge problem whether it affects other running processes or not. Then you describe a way in which other running processes could be affected anyway.

I don't see the point of making this argument at all when it's pretty clear that any of these unexpected outcomes would be disastrous and create an awful end-user experience.

The reality is that the decision to do this is most likely a business decision *and* a quality decision. These are both things that Apple cares rather deeply about. if the easiest way to solve all these problems is just to say "no mickey-mouse tools allowed," then Apple's decision makes total sense to me. I can't think of a single good argument why Apple *shouldn't* disallow such things.

First of all: We have no way to guarantee most of the things people state here. Should we declare a "moratorium" on discussions and conversations because of that? I'm a C/C++ developer and I have been doing it for 13 years. Naturally, you are free to believe it or not.

About my "two-sided" explanation: unlike some people, when I explain concepts or ideas, I try to convey all information I have; I don't omit the parts that go against my side. As I explained, all harm would be caused to the process that couldn't be properly placed to sleep. If other processes were coded to share resources (which would be virtually impossible since Apple doesn't allow multiple processes from the same application - maybe different processes from different applications?), there could be a problem.

Please explain why one application failing would be disastrous? As far as I can see, if an application fails, people will blame its authors, not Apple or other companies. And no honest company wants a bad image to their products.

At least, you agree that it seems more like a business decision. About the quality part, it is yet to be reasoned. I wonder if people would be enraged if IBM or Microsoft decided to tell developers how they are supposed to write code and which tools they can use or not.
post #39 of 171
Quote:
Originally Posted by ihxo View Post

because then your process will be blocking other process if the iPhone OS can't properly put your process to sleep.

Wait. Are you telling me that iPhone OS 4.0 throws us back into the times of cooperative multi-tasking? That's quite a few steps in OS architecture. Btw, in the end every binary will be linked against the system libraries (like libc) in order to be able to interface the OS anyway. So clean-up work could always be done at init time of the process.
post #40 of 171
Quote:
Originally Posted by Prof. Peabody View Post

I think you lost all credibility (and your status as possibly a non-trolling type), with this statement.

It's just absolute fantasy IMO and no serious developer who knew much about the current landscape would support it. Consider the following:
  • XCode is extremely easy to use and free.
  • Apple also allows pretty much any serious competitors' tools on any other platform by allowing C, and C++ as well as Obj. C.
  • The iPhone platform (85 million devices and counting!), is by far the biggest, the most vital, and the most profitable market to code for.
The idea that there is some group of serious developers, that have no talent with these popular tools but somehow have great talents with lesser tools is a joke. The idea that there is a group of developers so pissed off at Apple for doing this, that they are going to code stuff for Android first out of spite, (ignoring the giant iPhone device market), is similarly ludicrous. Finally, the idea that even if those two things were true, that these people would also only use tools that wouldn't allow their product to be easily ported (or in fact simultaneously developed for), the iPhone is also pretty silly.

In short, your analogy is completely unrealistic.

Are you a developer? How many apps do you have for sale in the store? If none, please stop calling me a troll just because I disagree with you!

XCode isn't bad, but it's also not very good. I work in Java, C#, Objective-C and C on a regular basis, and I'd say that all the Java IDE's are far better than XCode, and Visual Studio is slightly better. You're right that it's free, but you get what you pay for. The real shining star of Apple's dev chain is Interface Builder, but you can't use that for games anyway so that's irrelevent.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: iPhone
  • Apple's prohibition of Flash-built apps in iPhone 4.0 related to multitasking
AppleInsider › Forums › Mobile › iPhone › Apple's prohibition of Flash-built apps in iPhone 4.0 related to multitasking