Apple Eases Up on Restrictions on Interpreted Code in iPhone Developer Agreement

[Mr. Zorg]

Unless otherwise approved by Apple in writing, no interpreted code...

Let's hope that Apple will go through some common game development toolkits and the like and "pre-approve" them separately. I can't imagine the headaches of various game developers trying to get permission for each and every app using a game toolkit. Particular since games is far and away the largest segment of the App Store. Yikes.

 

[TurboSC]

That's great, but still no word from Unity about the status of the engine... I had a few games in the pipeline and we're still kinda in limbo regarding the use of Unity... I guess we'll find out when iOS4 gets here....

 

[Moonjumper]

There are good and bad options to help a developer, just as there are good and bad programmers.

Unity 3D, which I am using for a project, does the donkey work, allowing me to concentrate on being creative, which is where the user gets value.

Middleware is a large part of the games industry, all the way up to the largest developers such as EA. Most of the opposition comes from the "not invented here" brigade.

The source doesn't really matter. What is important is quality and compatibility. As long as it performs well and doesn't break the platform, what is the problem?

I would rather the restrictions were based on metrics such as how fast it depletes the battery, frame rate, responsiveness, etc.

 

[BigJimSlade]

That's great, but still no word from Unity about the status of the engine... I had a few games in the pipeline and we're still kinda in limbo regarding the use of Unity... I guess we'll find out when iOS4 gets here....

I have a hunch that this wording was specifically designed for middleware like Unity. They will be able to get a confirmation from Apple that what they do is OK, and all their users can breathe easy.

And someone like me can drop Apple a mail saying "hi, I plan on embedding Lua in my ObjC/C++ iPad project so I can script my game entity AI. Is this OK?" and hopefully they will say yes.

 

[macsmurf]

I have a hunch that this wording was specifically designed for middleware like Unity. They will be able to get a confirmation from Apple that what they do is OK, and all their users can breathe easy.

And someone like me can drop Apple a mail saying "hi, I plan on embedding Lua in my ObjC/C++ iPad project so I can script my game entity AI. Is this OK?" and hopefully they will say yes.

On the other hand, they haven't actually responded to Unity yet. A fairly cavalier attitude towards the company and its customers, IMHO.

 

[dimmer-fj]

lso, is very nice have the option in code in a language less prone to make crashing app, buffer overruns, bad memory acces, manual memory managment, etc (like c and all other their bastard childs like obj-c).

**** dude, if you write code as badly as you write comments I'm not at all surprised your apps tend to crash. Have you considered a future in COBOL?

 

[muskratboy]

This speeds development time.

well that's great, if Apple had ANY interest in speeding development time. They don't.

from what i've seen in development, Apple goes out of its way to make programming the iphone to be as difficult as possible. Their documentation is ridiculously spotty.

Many, MANY calls are simply NOT documented anywhere. you have to just go looking, asking people until you find someone who knows exactly how to code that exact thing you are doing, because they managed to hunt it down from someone else at some point. it's crazy.

For whatever reason, Apple WANTS a very large learning curve for its developers.

It is kind of strange that apple works so hard to make developers work so hard. but they do. goofy apple.

I would rather the restrictions were based on metrics such as how fast it depletes the battery, frame rate, responsiveness, etc.

Right... THAT will go MUCH faster and smoother than approval now. An arbitrary set of difficult to measure tests on an increasingly diverse product lineup. jeez man, do you NEVER want another app approved?

 

[pubwvj]

Antiquing

Hopefully Apple will allow for BASIC, LOGO, LISP and other fun languages as well as emulators for ancient computers like Sorcerer, Amiga, Tandy, Macintosh and the like. There are tons of great software out there in addition to the simple historical fun of those old machines.

 

[Consultant]

No, they are used by the smartest developers that understand that languages have different capabilities & power and leverage them.


And that not mean a resistance to work in the app store.

Also, is very nice have the option in code in a language less prone to make crashing app, buffer overruns, bad memory acces, manual memory managment, etc (like c and all other their bastard childs like obj-c).

LOL.

So show me some amazing iPhone iPad apps that are made this way.

I've seen a number of these ported apps, and they are mostly awful.

 

[mdriftmeyer]

Precisely. This is why I code everything in native machine language...nothing but 0s and 1s for me. Yes, it does take me 7 hours to write a simple "Hello, world!" program, but at least I have the satisfaction of knowing I'm programming the "right way". Those of you coding in C/C++ and Objective-C are obviously too lazy or stupid to know how to program properly.

Your joke would have been humorous if you said assembly language and talked about extracting a bit field and depositing it in a data register via something akin to the BFEXTU command for a Move operation on the Assembly for a 68000 processor.

 

[macsmurf]

LOL.

So show me some amazing iPhone iPad apps that are made this way.

I've seen a number of these ported apps, and they are mostly awful.

http://unity3d.com/gallery/game-list/

 

[thecartoonguy]

Oh, and the change also allows all companies to harvest analytics from the iPhone except companies that start with "G" and end in "oogle."

Can you give me another hint?

 

[TitoC]

It's funny how many people are out there bitching about Obj-C or C++ and the "limits" of writing for the iPhone and iPad. They want to write in what they know and not to get "deep" & "dirty" with X-code. They want a platform and device that will be able to take and implement a whole range of programs and be compiled into one package. All to make it easier for them. But they are missing the bigger picture here. If you really want to make a truly good iPhone or iPad App you will learn the native programming required. Period. But then, think about it. You will also be able to make an app for iPhone, iPod Touch, iPad or any Mac OS X device. You have now expanded your reach.

 

[Eric5h5]

http://unity3d.com/gallery/game-list/

Unity doesn't use interpreted code.

Anyway, it's to Apple's advantage to make development as easy and smooth and possible. The less time you spend fighting with obscure low-level functionality, the more time and energy you have for concentrating on actually making your app good and nice to use.

--Eric

 

[macsmurf]

Unity doesn't use interpreted code.

True. You can use a number of languages to script it, though.

Anyway, it's to Apple's advantage to make development as easy and smooth and possible. The less time you spend fighting with obscure low-level functionality, the more time and energy you have for concentrating on actually making your app good and nice to use.

I agree.

 

[muskratboy]

Anyway, it's to Apple's advantage to make development as easy and smooth and possible.

And yet they don't. why not?

seriously, we've put a lot of thought into this. it's not even subtle. apple makes developing way harder than it needs to be, and it has to be on purpose.

one thought was that they do it to reward/protect all the people who have been coding for osx... they put up a huge learning curve to build a little speedbump around the established guys.

apple does NOT think it's to their advantage to make development easy.

why do you think that might be?

 

[qtx43]

Does this mean we can perhaps start to see some game emulators such as MAME ported to iOS?

ok, I'm a little confused. Does this mean that theoretically, I could get Apple's permission to have an app that was built using the flash compiler into into the app store?

Not the way I read it. The purpose of MAME is to run any game on the original platform, and Flash compiler is to make pretty much any application. Nothing "limited" or "minor" about that and a general purpose compiler has nothing directly to do with the "advertised purpose of the Application". You could argue that calculator/spreadsheet programs were not allowed previously either, arithmetic is basically interpreted code. But it is just a one off interpreter specifically tied to the purpose of the program. You could still say calculators aren't allowed, because it's not minor, it's the whole program! Of course, Apple can change their mind and IANAL.

...in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.



 

[Stella]

Easier said than done when there are new Apps submitted all the time that don't fit into the existing rules or do things that were never imagined. I did site classification/analysis for a large search engine company once, and the rules were rewritten almost weekly for that reason.

Agreed - however, there is still vast room for improvement. Additionally, it would help if Apple didn't come up with new rules and then apply retro-activily, for example MyFrame. Developers don't know where they stand.

 

[Jason S.]

Who cares flash sucks and HTML5 is the future anyway. For those of you don't think so, check out the fact that freakin google made Quake2 run in HTML5. Can flash do that?

Yes. LOL.

And yes, HTML 5 is the future. It would have been the future regardless of Flash, because Flash is a plugin that is loaded from HTML elements. The entire web essentially is HTML, and HTML5 just defines the next step. Most of the stuff you see that is "HTML 5" is actually due largely part to Javascript. That HTML 5 Quake is heavy on Javascript. It would not exist without Javascript. And if you can do it in Javascript, you can bet you can do it in ActionScript (which is Flash's scripting language).

 

[mdriftmeyer]

Yes. LOL.

And yes, HTML 5 is the future. It would have been the future regardless of Flash, because Flash is a plugin that is loaded from HTML elements. The entire web essentially is HTML, and HTML5 just defines the next step. Most of the stuff you see that is "HTML 5" is actually due largely part to Javascript. That HTML 5 Quake is heavy on Javascript. It would not exist without Javascript. And if you can do it in Javascript, you can bet you can do it in ActionScript (which is Flash's scripting language).

Of course it would exist. They would have picked a different scripting language to write WebGL in and AJAX, etc.

 

[shervieux]

shervieux,
Is this for a company internal app?

If so you're not going through the app store, as you can setup your own internal enterprise app server.

If yes, then I'd suggest talking to fmtouch... I'm sure their business model is quite impacted by AppStore rule changes and they're on it.

Strangely none of their "apps" have itunes links, so I'm guessing their market is for internal apps.

Well,
one of them would be an app specialized for me (I probably won't sell it, but then again I can see how some of my colleagues my benefit from it too). Others are for market areas where I do not see many apps, but I know they would be great benefit. In looking at FM touch, it appears you can join their enterprise program, submit your database to their wizard which creates an app out of it (reports, forms, etc included) and returns a prototype. then when you are satisfied, you can submit your finished product to the app store to Sell.

This was taken from their website:

Create and Sell FileMaker Solutions on iTunes

Create a database, upload it to our wizard, submit to Apple! Sell on iTunes!

Learn more about the FMTouch Enterprise


Get your FileMaker solution in front of 50 Million iPhone and iPad users! Absolutely No coding!​

This sounds like a win for me, as the first few ideas I have are database driven, I always wanted to learn file maker (I am a MS SQL Server DBA - sort of as it is now. I say sort of, because you would really have to understand my job position)

I know some of you will say this is a lazy approach. However, I do not know obj-c yet and the few apps I have in mind currently are database driven but would not be something to live in a cloud somewhere. They would be more personal on your device. Then I may even expand it, into a full MAC OS X app - but marketing that type of software is harder than putting it out on the app store.

In fact I already have two of them fully written in MS-Access (from prior installations), but I want to make it more mobile friendly, and break free from having the Access dependancy and having to have a PC.

 

[johnnymg]

Precisely. This is why I code everything in native machine language...nothing but 0s and 1s for me. Yes, it does take me 7 hours to write a simple "Hello, world!" program, but at least I have the satisfaction of knowing I'm programming the "right way". Those of you coding in C/C++ and Objective-C are obviously too lazy or stupid to know how to program properly.

That's an amazing statement and I'm not sure whether I should laugh or cry.

I weep for the future....................

 

[Jason S.]

Of course it would exist. They would have picked a different scripting language to write WebGL in and AJAX, etc.

Okay. Name one. What other scripting language is interpreted in the browser without the use of a plug-in?

 

[CFreymarc]

So you're saying Apple is wrong to allow this? Blasphemy!

IMO, script code has it's place but the OP has a valid point. I have seen my share of Visual Basic code grown out of control into a crappy, schlepped foobar that should be taken out in to the public square and beheaded.

The problem is most "professionals" don't know when to stop coding in scripts and start coding native based on the complexity of the project. Script code gives you a quick return but that diminishes as features start going in these projects. Both Visual Basic and Flash are good examples of this.

At times, management -- epically if they never wrote code in their career -- cannot see beyond the "Does it work?" mindset. From that, dumping scripts to native code is a hard sell I have been in the middle of a lot. If you code native right, your maintenance cost does not go out of control like script code as the project matures.

I have seen many "five pounds in a one pound box" of script code grind development to a halt when new features can fit in the code base anymore.

Yes, I'm sure there are good OO guys out there that can do script code but they are few and far between. Not to mention they undersell themselves since they "just do scripts."

 

[puffnstuff]

so does this mean the flash compiler works?