HomePage RecentChanges iPhone331

In regards to: 4.0 Terms of Services, notably 3.3.1: “Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited.”

I am just getting a handle on this one, so these are only some notes:

The purpose

Performance, native look and feel, battery life, reduced memory and storage... Apple is making even the worst applications work well on the iPhone.

Conspiratorial... lock in to developing applications in XCode - this one is a little harder to believe as they encourage large game developers to port their apps to local iPhone.

Code generation

If you assume that 'intermediary translation' is about code generation (e.g. convert some form of code from a meta language into Objective C) then:

Any large scale application will do some form of code generation, whether this is from data to code (for performance or size) (good examples of this is using Blender code), or from templates, or from any common format (e.g. turning CSV files into native data for initial data in your application).

So is Apple really saying we can't do code generation, in which case a very large number of applications would be violating this... surely they mean something else.

Shared code

Many of the key example games that Apple promotes during releases of iPhone are ports of games, e.g. Myst and many others, use the C++ original C++ code, and wraps the interface calls. This is also how we are porting an application from Windows CE to iPhone - we are not going to spend another 5 years writing from scratch, but use the same code. So we move as much code to be sharable as possible.

How is this different?

Other language VMs

Lets face it... Flash sux ! I am not talking about embedded video, in that case it is nice, but flash applications on the web are just awful. Let me not get into all the reasons here...

Write once, run anywhere - aka Java or Flash - has advantages for developers. They write less code, and there is lots of examples and code out there. The down sides are all for the user: Performance; native look and feel; and more...

I can see why Apple does not want a VM/Interpreter in this fashion.

There are fashion to do it ok - imagine an example of embedding Perl in Apache - this is a first class installation, and all that is being done is choosing the language being programmed. You are still programming Apache. iPhone could do the same thing... Now my example is poor, but it is showing the difference between a system - aka: Java and Flash - that abstracts everything, and embeded language.

Apple market share

Apple market share is obviously important to them. They should have the right to defend this in a reasonable manner. Good examples could include: Single App store; Advertising through Apple; ...

What do I want

I want to write mobile applications. Myself and the people I write mobile applications for, do not want to tie themselves to one platform. Already we write applications that work on Windows, Mac and Linux - open source tools like Firefox work almost everywhere. This methodology has allowed Mac and Linux to take a larger market share. But... I don't particularly like Java and X11 type code running on Mac that don't have a pure native feel.

I want to write mobile applications that I can publish across multiple operating systems, where business logic (at least) is common between those releases. However I expect to write dedicated code for each system to support native user interfaces, and to do that I expect to use templates or other tools to help me.

By using these tools I can write 90% of my code once for multiple platforms, the alternatives would be to deploy for Windows devices (Pocket PC) and Android - using Java or similar technologies.I don't want that ! I want to write applications for iPhone too, that look and feel like iPhone apps - but my customers are not going to double my work to do so.

Lets hope that it is mostly smoke, that we don't have to worry, and think about this some more.

Software error:

Can't locate object method "endform" via package "CGI" at /data/scott.dd.com.au/wiki/modules/search.pl line 15.

For help, please send mail to the webmaster (webmaster@dd.com.au), giving this error message and the time and date of the error.