From: Arno P. <ar...@pu...> - 2010-04-17 20:31:29
|
Guys, believe it or not, but I have gotten an email from an Apple guy explaining Apple's intent regarding the change in the iPhone SDK license agreement! First a bit of background how this came about: I am a professor at San Francisco State University and a couple of days ago I received an email from our IT guys. They have been contacted by the Apple University Liaison who offered to loan an iPhone and a data plan for one month. Our IT guys forwarded this offer to me. I have exchanged mails with that Apple guy before. I know him by name and he knows that something like XMLVM exists. Given the recent change in Apple's license agreement for the iPhone SDK, I replied "thanks, but no thanks". Essentially, I wrote that it is Apple prerogative to define the terms and conditions of their SDK. However it is my prerogative what I advise to my students. I told him bluntly that I am very disappointed by Apple's most recent move and I will tell my students to move towards Android. I was very much looking forward to his response. I've added his entire response down below (but removing his name). This should be the most detailed clarification that Apple has given to date regarding their motivation about the latest change in the license agreement. Now here is the interesting part: the Apple guy wrote that "Arno had created a tool that, in a simplified description, recompiles apps designed for the Android platform for use on the iPhone platform, circumventing the developer tools Apple provides." All of you on the mailing list know that this is not correct. XMLVM emits Objective-C *source code* and it even creates an Xcode project. XMLVM depends on Xcode and does *not* bypass it. I will reply to the Apple guy to explain this detail to him and to ask him if this means that XMLVM is still within the legal framework on the new SDK license agreement. I will keep you posted. Arno ---Below the verbatim mail from Apple University Liaison--- Let me clarify a few things that Arno has mentioned… He is correct in that Apple recently clarified the Software Development Kit requirements for a variety of reasons. To receive approval for an App on the App Store Apple requires developers to use the developer tools Apple provides when creating software for the iPhone OS devices, which includes the iPhone, iPod touch and iPad. Arno had created a tool that, in a simplified description, recompiles apps designed for the Android platform for use on the iPhone platform, circumventing the developer tools Apple provides. Apple has clarified the use of the development tools for a variety of reasons. 1. Apple cannot guarantee that OS updates won't break unique ways vendors have implemented their independent development tools. Apple is innovating and advancing the platform very quickly. 2. Apple cannot innovate as quickly if they're dealing with legacy support for third party compilers. If there's a problem with an application, Apple is seen as responsible for the problem not the vendor. For example, the forthcoming iPhone OS 4.0 will support multitasking capabilities through a variety of APIs for applications. To optimize this for the best user experience, battery life and functionality Apple can implement these things with the development tools provided and cannot help third party development tools take advantage of these features if they have implemented something in a different way. Since 2007 Apple has released 3 major OSes for the iPhone and the 4th will be released this summer. We're able to innovate quickly and add amazing features because we also provide the development tools to write software for these releases and new features so that developers can take advantage of them. Supporting other development tools would slow down innovation and as Apple has experienced in the past. Often, when relying on third party development tools, these can often lag in their upgrades by as much as a year or more. By that time Apple may have already released yet another major update to the OS. 3. Apple thoroughly tests all applications submitted to the store. If an application is buggy, therefore potentially creating a poor user experience, this reflects on both Apple and the vendor when the App has been downloaded. Apple often identifies bugs in submitted Apps and helps the developer fix their problems before the App is available to the public. With Apple's testing tools we can control the environment and help the developers get the most out of the applications specific to the iPhone OS platform. If third party development tools were to be used Apple would not be able to effectively test the Apps and provide constructive feedback to the developer prior to posting a functional App on the App store. 4. Apple sees the use of the development tools as a key way to take advantage of a variety of features built in to the platform. If a third party development tool is used to convert software used on multiple platforms, similar challenges to the write-once run anywhere paradigm are faced. This can, in some cases, result in a watered down software application that doesn't provide the advantages that any particular platform provides whether it's the iPhone OS, Windows Mobile, Android, Symbian, WebOS or other mobile platform OSes. An alternative could be creating a tool that can convert software applications from other platforms and then utilizes the compilers for the iPhone to actually create the application. I'm not a programmer so I don't know how difficult or easy this would be. It could allow for the best of both worlds. A few notes regarding iPhone development, specific to the relevancy of the iPhone OS platform, access to devices and consumers. * The iPhone Developer University Program has more than 1000 universities and colleges who have joined the program from all over the world * There are more than 85,000,000 devices that have shipped that run the iPhone OS providing access to several million more potential customers * There are over 185,000 Apps available on the app store for a variety of reasons, including ease of development, ease of distribution and easy access to individual, small business or large enterprise developers. They have been downloaded more than 4 billion times in less than 2 years. * Apple changed the model for creating revenue for developers compared to any other development environment before it. Developers can sell as many Apps as they want for $99 per year. Apple keeps 30% of those revenues, which keeps the store up and running, provides bandwidth to download those Apps and eases the organization of those Apps. * Many students have created Apps in their Computer Science or Computer Engineering colleges and easily sold these through the App store. In some cases students have paid for their college tuition or started new company opportunities unthought of just 2 years ago. This is a great article that discusses the App Store Economy. It was written in January and just shows how in just a few months these statistics are old: http://gigaom.com/2010/01/12/the-apple-app-store-economy/ With less than 2 weeks on the market, just this afternoon a study showcased that already the iPad web used has rivaled Android and Blackberry: http://www.appleinsider.com/articles/10/04/15/web_use_of_apple_ipad_already_rivals_android_blackberry.html Please let me know if I can clarify any of the above items. Thank you, |
From: Panayotis K. <pan...@pa...> - 2010-04-18 01:48:26
|
I don't get it. Probably this guy needs to be better informed. 1. Someone should tell him that XMLVM *could* be used to provide iPhone-only applications. 2. About this part: > An alternative could be creating a tool that can convert software > applications from other platforms and then utilizes the compilers for > the iPhone to actually create the application. Isn't that *exactly* what XMLVM does? |
From: Wolfgang K. <wol...@xm...> - 2010-04-18 05:54:00
|
The sentence about alternatives - that's exactly what we are doing, isn't it. -- Wolfgang Sent from my iPhone On 18.04.2010, at 03:48, Panayotis Katsaloulis <pan...@pa...> wrote: > I don't get it. > Probably this guy needs to be better informed. > > 1. Someone should tell him that XMLVM *could* be used to provide > iPhone-only applications. > > 2. About this part: >> An alternative could be creating a tool that can convert software >> applications from other platforms and then utilizes the compilers for >> the iPhone to actually create the application. > > Isn't that *exactly* what XMLVM does? > > > --- > --- > --- > --------------------------------------------------------------------- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users |
From: Gergely K. <ger...@ma...> - 2010-04-18 07:36:53
|
Hi, I hope this means that Apple will allow XMLVM to exist, and it is not the independent, unofficial thoughts of a sales rep guy, who is "not a programmer". I don't know if he got the links to the xmlvm.org website + the Google Tech Talk slides of Arno, but there are nice diagrams in each to make it clear what XMLVM does. I would also like to suggest to separate the Android API library as an optional component. In fact, we are not using the Android library in our "real" projects. We code directly against the UIKit Java bindings. Thus the compiled applications are in essence native iPhone applications that use only legal Objective-C constructs (categories, public iPhone API). With the Android API they could argue that the marriage of the different UI toolkits will lead to inferior user experience. They could also see XMLVM as a threat of a flood of Android apps, the same way they saw a threat in Flash apps. In reality, you will have to change the UI design of your Android app anyway to match the Human Interface Guidelines, and the differences in the hardware (e.g. the absence of a "Back" button). So it makes more sense to keep the business layer / backend of the application platform independent, and code the user interface specifically for the platform (iPhone and Android respectively) Maybe it would make sense to create different diagrams which explains the above, and does not make the Android API a central use case of XMLVM. So I would like to ask that when you communicate with the "Apple Guy", you try to make it clear that XMLVM is not an Android "compatibility layer" (language from section 3.3.1). It is a "pre-processor" (term from the DaringFireball blog posting) which creates Objective-C code that has the same properties like any hand-written Objective-C code. Best Regards, Gergely 2010/4/18 Wolfgang Korn <wol...@xm...> > The sentence about alternatives - that's exactly what we are doing, > isn't it. > > -- Wolfgang > > Sent from my iPhone > > On 18.04.2010, at 03:48, Panayotis Katsaloulis > <pan...@pa...> wrote: > > > I don't get it. > > Probably this guy needs to be better informed. > > > > 1. Someone should tell him that XMLVM *could* be used to provide > > iPhone-only applications. > > > > 2. About this part: > >> An alternative could be creating a tool that can convert software > >> applications from other platforms and then utilizes the compilers for > >> the iPhone to actually create the application. > > > > Isn't that *exactly* what XMLVM does? > > > > > > --- > > --- > > --- > > --------------------------------------------------------------------- > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > xmlvm-users mailing list > > xml...@li... > > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > -- Kis Gergely MattaKis Consulting Email: ger...@ma... Web: http://www.mattakis.com Phone: +36 70 408 1723 Fax: +36 27 998 622 |
From: Joris V. <jbv...@gm...> - 2010-04-18 17:45:17
|
Ok, I think I'm beginning to understand what's going on here. I'm not really familiar with jailbroken compilation, but from what I've seen, is that some apps are compiled with custom gcc buildscripts. I can understand why apple would not want to support this. I also understand why apple would rather not have scripting languages/vms.. There's a reason why they don't do garbage collection on the iPhone. My assumption is that codegeneration tools will be allowed, also because it's a good thing for the iPhone ecosystem. Not everybody can create the same quality stuff in all languages / tools. There's a reason why tools and engines are used. Using middleware should improve overall quality, as there is less to focus on. This is of course well known. The problem Apple is facing, is the huge number of low quality apps. If you require to use Apple's tools, you will only have: * Developers that already worked with apple tools//xcode/objc * Developers that won't go for the platform * Developers that will take the effort to learn the platform * Developers that will learn the platform, but only to get up and running, and therefore missing a lot of the APIs.. resulting in the same 'bad' software. This, however, will NOT improve app quality. A lot of the apps available are created by one-man developers, and one of the things most developers can't do is design. If you look at normal software, it's the same story, and low quality software will be less known than good quality. There's one big difference. Normal software relies on google, and apple's appstore relies on releasedate, ratings, and weekly popularity. This model is nice for trends, but not for general apps. The same has been true for desktop software. How many people still use zdnet or whatever to find new software? Most people use software recommended by friends, and occasionally software recommended by blogs like lifehacker. Apple needs to realize that it can't control this. They can provide tools to support, but at this point they're inadequate. The appstore as a distribution platform IS a good thing. It provides users and developers an easy way to get and sell software. Apple can improve their appstore by having a searchable featured list, buddylist / recommendations, better searchengine. Though it still won't be good enough.. Maintaining a list of good software is hard (and next to impossible) work. So far my rant ;) On Sun, Apr 18, 2010 at 09:29, Gergely Kis <ger...@ma...> wrote: > Hi, > > I hope this means that Apple will allow XMLVM to exist, and it is not the > independent, unofficial thoughts of a sales rep guy, who is "not a > programmer". > > I don't know if he got the links to the xmlvm.org website + the Google Tech > Talk slides of Arno, but there are nice diagrams in each to make it clear > what XMLVM does. > > I would also like to suggest to separate the Android API library as an > optional component. > > In fact, we are not using the Android library in our "real" projects. We > code directly against the UIKit Java bindings. Thus the compiled > applications are in essence native iPhone applications that use only legal > Objective-C constructs (categories, public iPhone API). > > With the Android API they could argue that the marriage of the different UI > toolkits will lead to inferior user experience. They could also see XMLVM as > a threat of a flood of Android apps, the same way they saw a threat in Flash > apps. > > In reality, you will have to change the UI design of your Android app anyway > to match the Human Interface Guidelines, and the differences in the hardware > (e.g. the absence of a "Back" button). So it makes more sense to keep the > business layer / backend of the application platform independent, and code > the user interface specifically for the platform (iPhone and Android > respectively) > > Maybe it would make sense to create different diagrams which explains the > above, and does not make the Android API a central use case of XMLVM. > > So I would like to ask that when you communicate with the "Apple Guy", you > try to make it clear that XMLVM is not an Android "compatibility layer" > (language from section 3.3.1). It is a "pre-processor" (term from the > DaringFireball blog posting) which creates Objective-C code that has the > same properties like any hand-written Objective-C code. > > Best Regards, > Gergely > > 2010/4/18 Wolfgang Korn <wol...@xm...> >> >> The sentence about alternatives - that's exactly what we are doing, >> isn't it. >> >> -- Wolfgang >> >> Sent from my iPhone >> >> On 18.04.2010, at 03:48, Panayotis Katsaloulis >> <pan...@pa...> wrote: >> >> > I don't get it. >> > Probably this guy needs to be better informed. >> > >> > 1. Someone should tell him that XMLVM *could* be used to provide >> > iPhone-only applications. >> > >> > 2. About this part: >> >> An alternative could be creating a tool that can convert software >> >> applications from other platforms and then utilizes the compilers for >> >> the iPhone to actually create the application. >> > >> > Isn't that *exactly* what XMLVM does? >> > >> > >> > --- >> > --- >> > --- >> > --------------------------------------------------------------------- >> > Download Intel® Parallel Studio Eval >> > Try the new software tools for yourself. Speed compiling, find bugs >> > proactively, and fine-tune applications for parallel performance. >> > See why Intel Parallel Studio got high marks during beta. >> > http://p.sf.net/sfu/intel-sw-dev >> > _______________________________________________ >> > xmlvm-users mailing list >> > xml...@li... >> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> xmlvm-users mailing list >> xml...@li... >> https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > > > -- > Kis Gergely > MattaKis Consulting > Email: ger...@ma... > Web: http://www.mattakis.com > Phone: +36 70 408 1723 > Fax: +36 27 998 622 > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > |