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 - Page 2

post #41 of 171
Quote:
Originally Posted by kresh View Post

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.


cross platform like Flash means it's easy to port to another platform. Apple want's to make it as hard as possible to port apps to other mobile platforms.

Think Microsoft in the 1990's. you take open standards, bastardize them just enough to make it uneconomical to port software written for your OS to another OS
post #42 of 171
Quote:
Originally Posted by cynhgm View Post

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.

No, the iPhone OS is truly pre-emptive. And Apple's designs aren't so awful that they couldn't handle non-ObjC/C/C++ code. It's actually unusual for AppleInsider to claim that Apple would make such an awful design-- they're usually pretty pro-Apple. In reality, threads are threads and processes are processes no matter what language makes the syscalls. There would be absolutely no difference in suspending one versus the other.
post #43 of 171
Quote:
Originally Posted by Booga View Post

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.

Dude, calm down. I actually refrained from calling you a troll, I just said your status is in doubt because of the troll-ish (unrealistic) statement you made at the end of your post. I didn't argue against your whole post even, just the silly statement at the end which was, in fact, troll-ish.

If you work in Java, C#, etc. on a regular basis then you are a "serious developer" in the manner of how I was describing it in my retort to your post. The point being, that you will have no real trouble as a result of this decision by Apple. You seemed to be directly implying in your first post that there was some group of developers that were good, but for some reason unable to use the required languages or tools. Who are these people and what are these tools then? obviously they don't include you.

It was only trying to pass off that troll-ish fantasy of people shunning the iPhone platform (albeit temporarily), because of some ... (not sure if you gave a reason... spite?), that made me reply at all.

Microsoft "won" against the Mac ten years ago because it did the same things that Apple is doing now. It controlled a nascent platform with a firm hand while simultaneously providing perks, great tools and lots of money in the form of a gigantic new unified market to the developers. To suggest that Apple will fail because it's making the "same mistakes" is just ridiculous IMO.

Apple is courting developers. Apple is bending over backwards for developers. Apple is giving iPhone developers the best deal they've had in years. I'm merely maintaining that any "developer" that runs away from this deal because they only want to code in Python or Java and can't handle switching to some form of C is being foolish at best.

If the reason is that they want to code in Flash, then they aren't really even "developers" in my book. I can code in several types of "script" but I don't go around calling myself a "developer" as a result of that minor skill.
post #44 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.

As a developer and UI design I totally see apple's point of view, yes it's a business decision, but their business is delivering quality devices with excellent UEX, so what part of that don't you understand? Just curious how you separate the two.
post #45 of 171
Quote:
Originally Posted by ihxo View Post

maybe there could a flag for apps to op-out of multitasking.

Not all apps will multitask. Only those that use specific APIs will multitask. For example, IM apps don't need to multitask and will use Push Notification instead.
post #46 of 171
Quote:
Originally Posted by Booga View Post

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.

what don't you like about XCode?
post #47 of 171
Quote:
Originally Posted by TroubleStarter View Post

... At least, you agree that it seems more like a business decision. About the quality part, it is yet to be reasoned. ...

I would say that I don't actually know the complete reasons behind the decision and neither does anyone else on the thread here today.

I would agree that even if it were strictly a business decision it would still make sense and they would still do it, but quality means so much to Apple that I believe that some of the technical reasons figured into it as well.

Overall, people on forums (and I include myself) tend to have very little inside information and make broad sweeping generalisations. The reality is probably a lot more complex, but for that reason, the idea that the board was sitting around one day and decided to do this just to "screw Adobe over" (as some people seem to be arguing), is unlikely to be true.
post #48 of 171
Quote:
Originally Posted by PaulSorensen View Post

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.

Actually there is a perfect reason why Adobe can't do this... it's because they are talentless hacks that can't even develop a simple plugin that doesn't try to kill your machine through over work. If they can't get that right what makes you think they're going to add proper functionality to their CS suite?

Why isn't Flash Player using Cocoa and Apple's frameworks on the Mac? If they did then there's no reason Apple would be up in arms over Flash. Don't give me Adobe's crap about them not being able to do hardware decoding of H.264 because if they were using Apple's APIs they would be inheriting this from the underlying frameworks so any "technical limitations" excuse means Flash supporters are no better than what Daniel has written here.

If Adobe played the game then Apple wouldn't be so against what they're doing but Adobe chooses to do things their own way and it could have disastrous repercussions for the iPhone OS based devices.

I call truth to this article based on current actions of Adobe... or I should say current inactions of Adobe.
post #49 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?

The iPhone SDK Agreement is a single document. It's update happened to coincide with the release of iPhone OS 4.0 beta. But it does also apply to 3.2 as well.

It has to be agreed to so that apps can be submitted to the App Store.
post #50 of 171
I hope this is true because Apple may run into anti-competitive issues, if it is not. At best, it would have a negative impact on the image of Apple if it turned out the new agreement clause were intended mainly to stiffle competition.

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.

Your contention may be correct, but without evidence showing this to be the case, we have no basis for accepting its veracity, except your word. It will be a "believe me..." kind of acceptance of your contention. As a user, with a very old G3 iBook, I experience day-in-day that any site that has too many plug-ins, ads, and all those videos and visuals that many claim here to be based on Flash do freeze my computer, especially when I already have a gazillion applications open. My computer heats up very fast too.

As a user, why would I want the latter experience? If Apple can find a way to improve my viewing experience, all the better for me. That is my view as a user who simply wanted to use the product for the goals I wanted to accomplish.


Quote:
Originally Posted by Booga View Post

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

The premise of this statement is dependent on your prior statement. If the previous statement is not true, this is also incorrect.

I have yet to read an article here or be presented with a controlled experiment: a head-to-head comparison, where one component is changed, and all other variables are held constant to confirm your statement and your allegation.

From my experience creating websites and using available CMS, templates, modules, plugins and applications from third party sources, the rendering of a site depends so much on the optimization of the scripts, as well as the other components integrated. Just a small tweak, replacement of certain plugins, third-party applications, etc. -- to achieve the same goal -- can make a significant difference in the fast presentation of a website. Google, Yahoo and many other groups have done extensive studies on the topic of optimization of website presentation.

The same should be true with iPhone OS devices -- iPhone, iPod Touch and iPad; or for that matter any other mobile computing devices.

CGC
post #51 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.

You're right. I made a comment to ktappe's post in the thread yesterday saying as much. AI, of course, prefers to run with an imaginary concept that has no technical foundation. Maybe Apple PR liked the sound of it?
post #52 of 171
Quote:
Originally Posted by TroubleStarter View Post

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.

I can give 128 or 256 reasons. It's about the limited resources.

The problem with many programmers these days is that they have got used to large amounts of RAM and hard drive space and so when it comes to low resource devices like mobile devices they get stumped on how to do what they're used to doing with such limited resources. Old school programmers who've been doing programming for decades don't really have to worry because they've developed on platforms like Amiga, C64, ZX Spectrum, et al.

If an app doesn't close down properly it's going to hold onto resources that other apps can't run. In a multitasking environment on a device with only 256MB RAM that's going to cause issues down the track when all the other apps are playing nice and one app decides to rebel. Apple would have thought about this hence the reason they're trying to push XCode which incidentally they've been pushing on the desktop and laptops as was well noted with Photoshop and Office during the move to Intel (hmmm Adobe popped up again just then).
post #53 of 171
Quote:
Originally Posted by Aurchon View Post

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

Yea, I went to theflashblog.com and saw this.... "Comments disabled as Im not interested in hearing"... and the guy admits that he is paid to be a Flash evanglist...

Paid promoter, commenting on how his client is good and the rest bad.... Just so funny. :-)

Just a thought,
en
post #54 of 171
Quote:
Originally Posted by lowededwookie View Post

The problem with many programmers these days is that they have got used to large amounts of RAM and hard drive space and so when it comes to low resource devices like mobile devices they get stumped on how to do what they're used to doing with such limited resources. Old school programmers who've been doing programming for decades don't really have to worry because they've developed on platforms like Amiga, C64, ZX Spectrum, et al.

So using Apple tools suddenly makes a bad programmer into a good programmer? Bad code can be written in ANY language. Everybody knows and accepts that. So it isn't the reason for the new restriction. The business advantage it confers on Apple and the harm it does to their competitors is the reason.

Quote:
If an app doesn't close down properly it's going to hold onto resources that other apps can't run. In a multitasking environment on a device with only 256MB RAM that's going to cause issues down the track when all the other apps are playing nice and one app decides to rebel. Apple would have thought about this hence the reason they're trying to push XCode which incidentally they've been pushing on the desktop and laptops as was well noted with Photoshop and Office during the move to Intel (hmmm Adobe popped up again just then).

I wasn't aware that iPhone OS was based on System 7.
post #55 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.

Speaking as another developer, I disagree.

I have been playing with a complex app I wrote that saves state whenever possible (callbacks).

But, 4.0 manages to suspend/resume (save and refresh state) more granularly than I do in my app.

For example, I change a text field (customer name) that is used as the name of the state file, but never leave the field (no textFieldDidEndEditing callback). If I switch apps, the name change is recognized and [my app gets callbacks and] saves state to a new file, then deletes the old file.

The state file is rather large, containing customer data, shipping data, hundreds of items, etc.

Later, when I resume the app, the display is exactly as I left it... including the cursor positioned at the end of the customer name field, the kb popup, etc..

Further, I have yet been able to start enough other apps to force my app to terminate, rather than suspend.

I have done nothing to my app to implement this (other than state saving whenever needed, initiated by callbacks). I thought it too finicky to save state on every field change...

Apple's multitasking is, apparently, doing something, as it has made my app perform better than what I wrote!

The premise of this article, intelligent multitasking, has some validity.

.
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #56 of 171
Quote:
Comments disabled as I’m not interested in hearing from the Cupertino Comment SPAM bots.

What a twat.
post #57 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?


Let me play the devil's advocate here.

Let me try to represent what Apple might have in mind, as it creates its consumer-oriented products. The target consumer of Apple products is first and foremost, the average user -- not a techie. It is a for profit company, to profit, it must be able to persuade its average user that its products are good, and they are the best to use. [Cost is a secondary consideration.]

In the case of iPhone OS mobile computing devices -- iPhone, iPod Touch and now iPad -- Apple realized (more than it ever expected) that third party Apps is critical for the success of its mobile computing devices. This realization does not negate the primary focus of Apple -- to satisfy its target consumers. Further, while Apple wanted to dominate the market, it will not sacrifice quality -- both as a company philosophy as well as a marketing strategy. The latter is the reason why Apple is being copied, even if it is not always the first, and gets a lot of buzz whenever it introduces a new product.

With the above stated, let's start with the premise that the claim of this Apple Insider's article is indeed correct (I am not yet convinced that it is the case) :

Using Apple designated APIs and related scripts is critical for optimized multitasking.

In your statement "... it is the owners that make the decision...." you actually meant, it is the developer that makes the decision...." whether to use the designated APIs or some alternatives, e.g., the new Adobe Flash format. However, "... it is the user (the owner of the iPhone OS device) that will experience the consequence of the decision of the developer..."

If the non-technical average user (which is most of us) experiences problems with multitasking, or other potential adverse impacts -- slow rendering of application, decreased battery life, etc. ...." who will the average user blame?

The developer or Apple?

In reality, when using a number of applications (or scripts within an application), if something goes awry, it is difficult to isolate the problem. And, when operating multiple applications at the same time, identifying the culprit is even more complex.

In effect therefore, it will be Apple, not the individual developer, that will be blamed by the average user for the overall persformance of the iPhone OS product -- even if the problem(s) might have been instigated by the decision of specific developer(s), as implied by your post.

If the latter is correct, it follows why Apple has to ensure that it will do as much as possible to improve user experience without completely alienating the developer community.

However, like Apple, developers more than likely worship the same God. So ...

CGC
post #58 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.

You just start the app. Apple's multitasking figures out when/if to suspend or terminate the app based, apparently, on analyzing how the code runs.

Aha! Apparently there is a difference. When I compile the app in 3.2 it acts differently that when I compile in 4.0.

For one, the debugger is terminated in 3.2 when the app suspends... not so in 4.0... it just continues when the app resumes.

This tends to support the premise of the article that Apple may be doing things in the SDK 4.0 to assist intelligent multitasking at runtime.

.
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #59 of 171
TOTAL BS. Anyone who believes this needs their head examined. There is an agenda to kill flash which has nothing to do with multitasking, that's just the excuse of the day.
Groupthink is bad, mkay. Think Different is the motto.
Reply
Groupthink is bad, mkay. Think Different is the motto.
Reply
post #60 of 171
Quote:
Originally Posted by lowededwookie View Post

I can give 128 or 256 reasons. It's about the limited resources.

The problem with many programmers these days is that they have got used to large amounts of RAM and hard drive space and so when it comes to low resource devices like mobile devices they get stumped on how to do what they're used to doing with such limited resources. Old school programmers who've been doing programming for decades don't really have to worry because they've developed on platforms like Amiga, C64, ZX Spectrum, et al.

If an app doesn't close down properly it's going to hold onto resources that other apps can't run. In a multitasking environment on a device with only 256MB RAM that's going to cause issues down the track when all the other apps are playing nice and one app decides to rebel. Apple would have thought about this hence the reason they're trying to push XCode which incidentally they've been pushing on the desktop and laptops as was well noted with Photoshop and Office during the move to Intel (hmmm Adobe popped up again just then).

My McIntosh Classic had 25Mb RAM (???). It was able to run MS Word 5, I was even able to integrate scientific equations in there, did internet (imagine when they were only kb speeds), and most of the applications then that I needed for basic research -- including basic graphs, presentation, etc.

Honestly, for a very long time, there is not much in the succeeding versions of MS Word that I really used but the program has bloated with succeeding versions.

Every added line in the script can mean additional instructions requiring allocation of resources -- thus slowing execution.

Now, it is not unusual to have applications in the Gb range. Most of the scripts never used by the user, or they are repeated in other applications.

Apple is correct when it pared its OS scripts when it developed v10.6 for the OS X. And, further paring the OS X down to come up with iPhone OS.

CGC
post #61 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.

If Apple wants to assure the quality of user experience, it should do everything to make apps perform well, act like other apps, etc.

Quote:
Originally Posted by ihxo View Post

maybe there could a flag for apps to op-out of multitasking.

This is not the way Apple does things... how frustrating would it be for the user if some of his favorite apps suspend/resume and others terminate/reload.

.
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #62 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 <snip> 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.


Absolute B.S. If this were the case, Apple would have spelled out clearly which compilers could be used to generate the object / binary code. They didn't. They specified which language the code could be written in.

Without compiler introduced knowledge, the OS will have absolutely no idea what source language was used to write the original code.
post #63 of 171
Buy long-term shorts on Adobe.

Wait until they are devalued, hen buy stock for the inevitable Apple purchase.
post #64 of 171
Quote:
Originally Posted by Prof. Peabody View Post

It was only trying to pass off that troll-ish fantasy of people shunning the iPhone platform (albeit temporarily), because of some ... (not sure if you gave a reason... spite?), that made me reply at all.

...

Apple is courting developers. Apple is bending over backwards for developers. Apple is giving iPhone developers the best deal they've had in years. I'm merely maintaining that any "developer" that runs away from this deal because they only want to code in Python or Java and can't handle switching to some form of C is being foolish at best.

Language syntax is easy. It's the supporting APIs that take time to learn and become fluent in. It's hard to be fluent in more than one or two at the same time. Context switching cost isn't just a programming concept.

For large dev teams porting to ObjC is just something one part of the team does. Even if they have a large of legacy codebase and tool chains. It's mildly annoying to not have a common cross-platform codebase but they're big. Just part of the cost of doing business and they can afford it for such a large potential user base.

For small dev teams they simply target the largest market (iPhone/iPad) and ignore the other mobile targets. Their codebases are minimal and their toolchains are what Apple provides. Ignoring for the moment the small teams that use things like Unity or Torque to develop games.

It's the middle size studios/teams that really need these cross platform environments to compete with the big boys and stay as nimble as the small guys.

Small indy game teams also often depend on a game engine to do the heavy lifting and do the game logic in TorqueScript or C# (I think) for Unity.

Our strategy was to port our legacy business logic written in C# and use Monotouch. That's all up in the air now. From a business case standpoint it's one thing to have a UI team dedicated to the iPhone/iPad and keep our core desktop apps in C# and unify it under Monotouch.

It's a completely different equation if the entire codebase has to be ported to ObjC. Yah, so for us it's going to take a lot longer to get onto the platform if Monotouch is out of the equation. It's not the inability from a technical perspective but the inability from a business/resource perspective.
post #65 of 171
Quote:
Originally Posted by chaywesley View Post

Without compiler introduced knowledge, the OS will have absolutely no idea what source language was used to write the original code.

Exactly. This is the key point that proves the decision isn't technical. Apple makes no prohibitions on compilers, just source languages. Their compiler, llvm, is open source anyway and there is no evidence of iPhone specific changes to support multitasking. If they're doing anything tricky at all (which I highly doubt), it's at the runtime level, and in that case what source language you use is entirely irrelevant.

Apple isn't doing anything magical to support multitasking, despite what the RDF of Job's presentation might have you believing. I've read through the API diffs of the new beta and there's nothing special there. It's not even a client/server model for background processes as some have suggested. It's just plain old multitasking. Except your app gets killed after a while if the user forgets to close it, and there are some API hooks to integrate with system services (like the lock screen media player controls), and they expect developers to do a more fine-grained job of saving their app's state when their app actually does quit so that it can be restored more quickly and accurately when the app relaunches.

Apple is banning all other programming languages not for technical reasons, but because it is the most comprehensive way to block Adobe. Unfortunately, there will be a lot of unnecessary collateral damage because of that decision. But Apple apparently has no problem killing a bunch of friendlies in order to get a few more bad guys.
post #66 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.

Having not submitted my first app for approval yet, I don't know the process. I think the technical limitation probably has more to do with HOW the compiled applications are structured.

Applications transcoded will have a different application structure making it more difficult for Apple to AUTOMATICALLY scan them for offending API's etc. [different from code compiled via Apples compiler.]

I think the whole 'checking for multi-tasking' line of reasoning is a load of crap. The main thrust is to ease Apples approval process as much as anything.
post #67 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.


Why?

Quote:
"[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.

Because?

Study the Mach microkernel and it's recent child, the XNU kernel. The messaging model is now being streamlined back to leverage the kernel properly with the highest level of efficiency.

Within an embedded platform, efficiency is paramount. In a laptop, desktop, workstation, one has latitude.
post #68 of 171
Quote:
Originally Posted by amitofu View Post

Exactly. This is the key point that proves the decision isn't technical. Apple makes no prohibitions on compilers, just source languages. Their compiler, llvm, is open source anyway and there is no evidence of iPhone specific changes to support multitasking. If they're doing anything tricky at all (which I highly doubt), it's at the runtime level, and in that case what source language you use is entirely irrelevant.

Bingo. Programming languages are functionally equivalent if complete. If you want to write in lameo++ and can compile it or even translate to Obj-C and compile then bingo done. This is 100% a red-herring. The compiler is likely the key but as you say if open source where's the secret sauce?

An API call in an OS doesn't care if C, Fortran, Java, BrainF*ck (yes a real language), etc. calls it as long as the data types work right and you have the right tool support. I find it interesting in fact that the language is the issue. If there was some magic here the COMPILER would be the issue! Since it would put in secret sauce, but a lang -> ObjC -> secret would of course work just fine and you note the legal terms are quite clear about this.

Right now my BS o' meter is red lining...I'd love to see some very explicit details on what this is technically but so far nada. If it something unusual that might be cool to know about, but right now this is all a lame discussion and it's quite sad that CS educated people are NOT jumping all over this as the BS that it is at least give the current level of information provided.

Right now simply declaring one PL or another off limits is akin to saying English is a vastly superior language to Chinese. Tell that to anyone in China and both can express ideas albeit it in different ways. PLs are no different. Lame lame lame Apple

Signed someone who loves Apple but hates partisan programming which is what this is.
post #69 of 171
Someone please correct me or explain this to me, because due perhaps to my limited programming skills, I can't understand how apple can gauge what original high level language you used if the program submitted to the app store is in binary? I am confused...
post #70 of 171
Quote:
Originally Posted by myapplelove View Post

Someone please correct me or explain this to me, because due perhaps to my limited programming skills, I can't understand how apple can gauge what original high level language you used if the program submitted to the app store is in binary? I am confused...

A compiler will output certain things that are almost signatures and these can be detected if you like using the idea of "fingerprinting." This is done in many aspects of computing, for example you can fingerprint a source OS simply by looking at a few TCP packets using something like nmap they'd apply the same principle here. Likely they will look for the translation signatures of CS5 and say not allowed! Of course Adobe can fuzz this but it will be a nice cat and mouse game.

It brings up an interesting point of if you run some obfuscator or translator afterwards how they are going to keep up? There may be a new business model some exe-scrubber to allow for App store clean submission while writing in the language of your choice. So given that to keep Apple in a positive light a new theory ...since they are taking many of the new features of 4.0 from jailbreaker efforts anyway....is just maybe they wanted to give these people a new area to get into...code signature fuzzing. It was a move of kindness not malice for Apple...keep these people productive with a new mission :-)
post #71 of 171
Quote:
Originally Posted by tapper View Post

A compiler will output certain things that are almost signatures and these can be detected if you like using the idea of "fingerprinting." This is done in many aspects of computing, for example you can fingerprint a source OS simply by looking at a few TCP packets using something like nmap they'd apply the same principle here. Likely they will look for the translation signatures of CS5 and say not allowed! Of course Adobe can fuzz this but it will be a nice cat and mouse game.

It brings up an interesting point of if you run some obfuscator or translator afterwards how they are going to keep up? There may be a new business model some exe-scrubber to allow for App store clean submission while writing in the language of your choice. So given that to keep Apple in a positive light a new theory ...since they are taking many of the new features of 4.0 from jailbreaker efforts anyway....is just maybe they wanted to give these people a new area to get into...code signature fuzzing. It was a move of kindness not malice for Apple...keep these people productive with a new mission :-)

Ok, I see thanks very much for the info, appreciate it a lot.

lol, about the last comment, another way to spur innovation!
post #72 of 171
Quote:
Originally Posted by Booga View Post

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

I am always intrigued by people who claim, 'it isn't rocket science.'

The tens of thousands of 'smart' people working in all these companies that have struggled with implementing such stuff must be morons in disguise.
post #73 of 171
Typically biased article writing from Apple Insider, but good for a quick laugh I guess.

Android's multi-tasking is superior to Apple's, as it's true multi-tasking and not a half hearted attempt which only multi-tasks a few special cases. As for needing a task manager, iPhone OS 4 has one too, so to bash Android for needing one seems rather hypocritical.
post #74 of 171
Quote:
Originally Posted by John.B View Post

Then where is Visual Studio for Mac OSX?


Textedit? You don't need visual studio to compile a .net app it's just ms's version and they don't stop you using 3rd party versions.

Quote:
Originally Posted by anonymouse View Post

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.

firstly shouldn't it still be the developers choice. Secondly why do you assume writing in another language means you can't still use the api's. I may be wrong and apples language may be that bad but in .net there's no problems mixing vb with c# and then hooking into a com object, don't see why this should be any different.

Quote:
Originally Posted by Prof. Peabody View Post

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.

Your argument of no tallent is kinda flawed in that objective c is from the 80s and in the modern languages the tools people use didn't exist over 10 years ago. The fact someone may not be great at objective c doesn't mean there not good it just means they specialise in something else. If you want to be great at any language you have to do it full time and if someone can write a decent compiler that compiles to iPhone there's no reason it can't be as good as something written in Xcode.
post #75 of 171
Quote:
Originally Posted by anantksundaram View Post

I am always intrigued by people who claim, 'it isn't rocket science.'

The tens of thousands of 'smart' people working in all these companies that have struggled with implementing such stuff must be morons in disguise.

I 'm always intrigued as to why rocket science gets all the credit, should have been "it isn't software development"... Anyway everything is simple and everything is complex ultimately, I don't think there's a universal notion of "difficult" to set the standards by.
post #76 of 171
Quote:
Originally Posted by reliason View Post

Applications transcoded will have a different application structure making it more difficult for Apple to AUTOMATICALLY scan them for offending API's etc. [different from code compiled via Apples compiler.

No, it won't. API calls are done with the same ARM machine instructions. That is what you are scanning for.
post #77 of 171
This is a bullshit propaganda article without any basis in fact and I'm surprised that Daniel Eran Dilger will actually put his signature to it. There is no way that the OS executive (the kernel process manager) can or needs to know or distinguish between different compilers in the way it handles process scheduling.

I've re-programmed kernel executives as part of my computer science education and for me the distinction between machine code and abstract computing languages is pretty obvious and part of the fundamental freedoms of the programmer to choose his own tools

That lawyer and MBA types (including Steve Jobs) at Apple Inc. think they can exploit their ownership over the iphone OS platform to force a straightjacket upon developers is to me pretty disgusting. I'm a recent switcher (2005) - although I've been using computers since 1983. I was quite fascinated by the iphone platform and saw it as a great way to win hearts and minds for the Cocoa API but I have to say after the recent draconian moves by Apple to restrict content and free choice for developers and consumers on the iphone platform I am NEVER going to purchase an iPad or iPhone. I will go for Android although on the desktop I will still prefer OS/X.
post #78 of 171
First, let me say that I learned to program (1958) before there was anything called CS, OOP, compilers, interpreters, etc. (That's before Fortran, CoBOL, BASIC, and, yes, Flash).

Over the years I've made some effort to stay current, but programming is not my major activity... I do it for my own amazement, more than anything else.

I am not a programmer, but I know how to program (I've probably thrown away more [bad] code than a lot of you have written


Let's consider one aspect of the topic D'Jour:


A crucial element of multitasking is efficient use of RAM, whether RAM is dirty (needs to be saved and refreshed or refreshed only), and what resources the OS must expend to determine which memory is no longer needed. Also important is that RAM is organized in blocks (based on usage) that can be easily manipulated when necessary.


One thing that is apparent is that memory management in the iPhone OS is different than many other systems.

In iPhone OS XCode the programmer is responsible for acquiring memory when needed and releasing it when no longer needed.


Other languages and most interpreters remove this burden from the programmer. The "system" goes through a process called "'garbage collection" to detect memory that is no longer needed and release it to the system.

Garbage collection takes precious CPU cycles and seconds... and, likely, will result in poorer performance and poorer memory usage than a knowledgeable programmer performing manual memory management.


I haven't looked at Java or Flash for quite a while. But, AIR, they use garbage collection.


How does someone write an app that depends on system-supplied garbage collection and then deploy it on a system (iPhone OS) that doesn't provide this service?

Have Flash and Java been enhanced to support manual memory management?

Do apps written in other languages (than those supported by iPhone OS) get translated to:

1) use a kludgey, heavy-handed manual memory management?

2) get packaged with a run-time that provides garbage collection within the app?

3) use some other device to efficiently integrate with the iPhone OS multitasking (and memory management) capabilities.


It seems to me that the best way to assure the quality of the user experience is require that the providers of iPhone programs use the tools and procedures specified by the manufacturer...

Am I wrong?


Doesn't [even] Mr. GoodWrench require only GM authorized Parts and Procedures?

.
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
"Swift generally gets you to the right way much quicker." - auxio -

"The perfect [birth]day -- A little playtime, a good poop, and a long nap." - Tomato Greeting Cards -
Reply
post #79 of 171
what really fascinates me about all this Apple vs. Flash controversy lately is how many people suddenly champion Flash/Adobe as if it is somehow sacred. since it too is a proprietary closed software licensed for profit by one corporation - morally certainly no better than any other, including Apple.

the answer is many developers and users have simply become addicted to it. like cheap drugs. when it was new it was the first good solution to a huge problem - a great high! - so it was widely embraced. ok. eventually it achieved near monopoly status in its category. but now there is a rival, Silveright/MS, and a new kid in town, HTML5/Apple. but the Flash mob won't switch, they're hooked. (and some make their living from it, of course, so you can understand their alarm.)

but nobody owes Adobe anything. their stewardship of Flash when it had to the market to itself was poor. stay addicted to it or kick the habit, but please drop the moral posturing.
post #80 of 171
"Enhanced" to support manual garbage collection? Are you smoking crack? Automatic garbage collection is recognised as one of the greatest achievements of compilers in the 20th century. That Apple would drop this in favour of multitasking is beyond me.

BTW this is not about Adobe vs Apple. This is about Unity vs Apple. And the freedom of programmers to choose their own tools rather than be forced by lawyers to use what is in the latter's capital interest.
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