There seems to be a lot of confusion regarding deploying Adobe Air apps to ios after the restrictions were lifted. Before apple lifted the restrictions you had to go through the process documented here: http://blogs.adobe.com/cantrell/archives/2010/09/packager-for-iphone-refresher.html using the Packager for iPhone. But now that the restrictions have been lifted and the Air 2.7 update we can use the same ADT tool in the flex SDK that we use with all air applications.
My understanding is that the old Packager for iPhone (PFI) some how converted actionscript code into native objective C in order to be accepted by apple.
If that is correct does the restrictions being lifted mean that the ADT tool is not converting to objective C and is only bundling the AS3 .swf and air player together when creating the .ipa app file?
What exactly changed in the Air deployment process after apple lifted its restrictions?
If anyone could point me to some documentation on how the .ipa file is being created behind the scenes I think this would really clear some confusion.
Thanks for the help
Nothing really changed; apple just lifted the ban. The ban wasn't just on flash-created apps, it was on any tool that created any kind of intermediary language or used a virtual machine, etc. What the PFI does: it actually uses the LLVM compiler to statically compile actionscript 3 BYTECODE (not AS3 source) into native ARM assembly. So essentially when you're deploying an IPA it's the same idea as publishing a SWF to an exe (as in the publish settings) in the sense that both your SWF application and the flash virtual machine are bundled together, except instead of being an exe where the code inside is x86 ASM with AS3 bytecode executed along the VM, it's ARM. The PFI and all its classes were simply merged into the ADT tool. The PFI contained a LLVM dll which is accessed through various LLVM java classes that were added to the internal adobe version of the ASC or actionscript compiler. These LLVM classes and other associated classes, however, are not open source, which adobe is allowed to do, even though the ASC is open source because it's licensed under the MPL or mozilla public license, which permits the use of the open source code in proprietary closed source applications without sharing your changes.
For proof of all that I've told you, just download the new flex SDK that includes the ADT with the PFI merged in and you'll find the LLVM dll's etc. Further, you can decompile the ADT jar and see all the LLVM classes. The LLVM classes ( I believe ) intercept the ASC bytecode through the class GlobalOptimizer, or at least it did back in the day... they've probably changed that. The only other thing that has changed is that apparently Adobe has optimized the PFI (now merged into ADT) quite a lot. More info here:
http://blogs.adobe.com/cantrell/archives/2010/09/packager-for-iphone-refresher.html
http://www.leebrimelow.com/?p=2754
Update
Here is an official Adobe article confirming the things I've told you:
http://www.adobe.com/devnet/logged_in/abansod_iphone.html. I also should clarify that I've really over-simplified the process behind the scenes and appear to me mistaken in one of my points. I guess somehow the PFI actually merges the AS3 bytecode and the VM into a single seamless executable that doesn't use JIT compilation, and thus would technically not be a virtual machine? Not sure on that point, but the above article does seem to imply this:
"When you build your application for iOS, there is no interpreted code and no runtime in your final binary. Your application is truly a native iOS app."
Related
I'd like to know what is the simplest way to build a video playing app that runs under iOS. I'm using the JUCE Framework that allows to develop under Windows with e.g. Visual Studio and code programs for Android, iOS, etc.
I've looke around libVLC, FFMPEG and so on. But all of these are intended to be developed under Linux, I think.
Does somebody have an easy Example for JUCE to build an iOS player app working under Visual Studio?
Coding
There's nothing to step you writing the code itself; IDEs are just fancy text editors with other tools built in (in the case of Visual Studio, a full code translation toolchain).
You'll probably find that things like code completion won't work, as JUCE will #ifdef parts of the codebase out depending on what project type you're launching, but last I checked (when I worked there) there was no Visual Studio iOS project exporter available, so you'll have to just use a Windows compatible one and program through that.
Building
In order to build an iOS app, you need a Mac. If you take a look at the documentation, it states:
For iOS projects, connect to a networked Mac and start the Mac emulator from Visual Studio.
No cross-platform library that I know can circumvent this restriction; I believe it's due to a legal requirement enforced by Apple.
With that said, if you don't own a Mac you might be able to "rent" one using a service like Mac In Cloud. I'm not a lawyer, some please make sure you check the legality of using such a cloud service for building iOS apps before doing so.
Debugging
Since you need to be able to compile in order to debug a specific build of the application, the section on building applies. Of course, there's nothing stopping you from debugging it without a build by reading the source code carefully, but I'm guessing that's not what you're asking about.
There is any way to submit to the App Store an Qt Quick Controls application
under LGPLv3 license without violating App Store rules?
What i want to do is to deploy my app on iOS store using a dynamically linked version of the Qt libraries.
I tried to find an answer in every forum but seems very difficult.
Any suggestion is very appreciated.
Thanks in advance.
App Store does not care which license you use. It is the users of your application and the Library authors who care. The main point of the LGPLv3 license is that the end users must have the possibility to replace the library with their own modified version. This is very important to understand, dynamic / static / everything else is just distracting.
Let's move to Qt. It is available with LGPLv3 license on major Desktop (Windows, OSX, Linux) and mobile (iOS, Android) operating systems. Suppose you develop an application and want to keep your source code closed. On the Desktop you can link dynamically to Qt libraries. When the end users install your application, they can replace Qt libraries in the following way:
Compile their own version of Qt libraries
Navigate the the location where the application is installed
Replace original Qt libraies that were shipped with your applicatoin with their own modified versions
Looks easy, right? The main goal of LGPLv3 is achieved. The user can replace libraries.
Moving to the mobile platforms, starting with Android. Even though you link dynamically to the Qt libraries, we now have a small problem. The user can not navigate to C:/Program Files/YourApp and replace Qt libraries, because it's Android. Rooting is not an option, since it doesn't work on every device (and might not be legal). Remember, the main goal of LGPLv3 is to give the users ability to replace the library and run the modified version of your application on their device.
Solution? Provide .apk file to every user who installed your application with detailed instructions on how to:
Unpack your .apk file
Replace Qt libraries
Zipalign / pack / signtool to a new .apk
Install .apk with modified Qt libraries
Let's talk about iOS. Many say it is not possible to use LGPLv3 with iOS because of static linking. Wrong. Again, you just need to give the end user the possibility to replace Qt libraries. How? Provide your object files for the end user to relink. Or even better, put all your application code and resources in a separate Qt Quick plugin which will compile in a static library archive (technically just all object files concatenated together) for iOS. Then for every user who installed your application you have to provide instructions on how to replace Qt libraries:
Download project files and object files from your website
Download XCode and developer tools from Apple website
Replace Qt libraries
Deploy application to your device
Before this was not possible because in order to deploy on the device the user had to enroll Apple Developer Program. But this is not the case any more. You can launch your app on a device using a free Apple ID account
The end user rights are protected. They can replace Qt libraries. Just make sure you do required steps:
Mention in your application that you use Qt libraries and also mention you use them under LGPLv3 license. Provide a link to LGPLv3 lincese.
Make sure your setup of replacing Qt libraries work. Set up a clean virtual machine and do everything step by step. Document it for the end users.
When the users who downloaded your application want to replace Qt libraries, provide them everything so they can do it.
Actually I don't think anyone would care. But you have to be ready just in case. Do not scream you use Qt LGPLv3 on Qt forums, but make sure you have it visible somewhere down in your application's "About" screen. Qt company does not have resources to scan every application from the App Store if it uses Qt or not. Neither they will touch you if you are a small-near-zero-profit. They have more important things to do.
It is very dissapointing however to see absolutely no help from people who work in Qt on the LGPL subject. Most likely all developers were instructed to answer "IANAL, please contact our legal department". The legal department will tell you - buy our commercial license, it's the only option. On the Qt website you can find Obligations of the LGPL. I am not surprised, there is no word about static linking and providing object files for re-link on this page. Qt company simply prefers not to tell anyone it is possible.
From my point of view LGPL was a huge step which enabled a lot of application to use Qt without disclosing their source code bringing huge popularity to Qt. Not to mention Nokia was the one who sponsored Qt on Mobile first (Symbian and then MeeGo).
Also thinking about MeeGo and Blackberry, there was no problem with developing closed source mobile apps that use Qt and publishing them in respective app stores. No commercial license needed.
Update:
This has been done before. LGPL is possible with static linking and App Store. https://news.ycombinator.com/item?id=4302517
In case the question gets closed as off-topic, I copied the answer here
https://opensource.stackexchange.com/questions/6463/in-2018-if-i-use-c-qt-5-10-0-to-build-a-closed-source-application-requires-ope/6495#6495
Yes, it's possible.
You can use this Qt app template:
https://marketplace.qt.io/products/qt-lgpl-app-template
On IOS it's impossible to relink the App, so it's LGPL V3.0 incompatible (user can't replace Qt libraries)
But this template generates a redistributable .zip Qt project on every rebuild.
Their entire private project is distributed in a compiled .a library, so a user can open project in Qt Creator, rebuild their application and load it on their ipad / iphone, and your source code stays protected
Note: If you are using the qtquick compiler, you must relink it to the same version of Qt.
This .zip file can be uploaded to your own URL or you can add it to your software resources.
You can use the same template in an Android app, a static Windows app, etc.
It's the same as #psyched says, but 100% automatically.
I am thinking of learning Haxe, after extensive as3 experience and some javascript/nodejs but several people have stated that haxe compiles into a swf and encapsulates it to be run on "insert platform here" making it both incompatible with some native features and with significant overhead.
I am interested in knowing about ipad/iphone specifically. Does this somehow compile into a format compatible with such apple devices? I mean does it translate to x-code then compiles it or what?
I have various clients that want cross platform versions of the same application and Haxe looks like a simple, elegant solution but since my clients are from US, Apple products are a concern to me.
My scope of projects revolves around simple apps with server services and maybe some webcam/microphone action, if this helps for an answer. Cheers.
haxe compiles into a swf and encapsulates it to be run on "insert platform here" making it both incompatible with some native features and with significant overhead.
This is a big misconception. Though as with any cross-platform tech, it's a somewhat nuanced answer.
First, know that Haxe is simply a programming language that compiles to many other language (& bitcode) targets, e.g. JavaScript, C++, PHP, python, SWF, hl, neko and others.
Compiling to C++ is the typical path when building native Android and iOS apps (and Windows and Mac apps, for that matter). Also, Haxe is just the language. Usually a framework is used for building apps, and there are many choices -- OpenFL, or its predecessor Haxe NME, or heaps.io, or HaxeFlixel, or luxe, or Kha.
Each framework is unique in paradigms and workflows, but for example, last time I used OpenFL, it exports an XCode project with C++ code when building for iOS. You are then expected to open and compile the project in XCode and onto your device (or for the app store), just like any other iOS app.
While using a framework is a common way to build apps with Haxe, you can roll your own, if you like, for example:
Compile Haxe to JavaScript, using externs to leverage existing JS libs (e.g. here's a set of Pixi.js externs, or the built-in jQuery externs), and develop mobile web apps with Haxe. Note: many of the above frameworks support a Haxe -> JS workflow.
Compile Haxe to SWF, and then use the Adobe AIR SDK to package your app as a native iOS / Android app. This avoids XCode and is possible from Linux and Windows (where compiling an XCode project is not). Perhaps this flow is what those other people were talking about.
Following the instructions on the PlayN wiki I was able to get the "hello" PlayN sample running on the iOS simulator. However, when using MonoStudio, I was told that I need to upgrade to an Indie license or higher to compile the code. (Apparently I was using 33+ features which required it.) When I activated a trial edition, the sample compiled and ran fine on the simulator.
The PlayN wiki seems to indicate the you'd only need a license if you plan on testing on a real device. Is it wrong or am I missing something?
Also, I thought the idea behind PlayN was to build a free, open source game engine on top of free, open-source technology. Mono is both, but MonoTouch is neither. Is there another option or am I stuck with shelling out $1000/year to use iOS (which so far seems far from fully implemented on the PlayN side of things)?
Right now, there isn't. Sorry its disappointing, but its the nature of iOS. Its a very non-free platform.
Perhaps you can try your hands at writing a cross compiler, and release it under an opensource license? You can try basing it on http://gcc.gnu.org/java/.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Any way to use some Scala for iOS coding?
Would it be possible to use the Scala.NET implementation, and then MonoTouch to run Scala code on an iOS device?
I have not been able to find a page with binaries of Scala.NET that I can test, so the following are just general guidelines as to what you can do with MonoTouch and .NET languages.
MonoTouch can run any ECMA CIL that you feed to it. When you consider using a new language with Monotouch, there are two components that come into play:
Tooling for the IDE
Runtime for the language
The tooling for the IDE is the part responsible for starting the builds, providing intellisense and if you use Interface Builder, it creates a set of helper methods and properties to access the various outlets in your UI. As of today, we have only done the full implementation for C#. What this means for an arbitrary language is that you wont get the full integrated experience until someone does the work to integrate other languages.
This is not as bad as it sound, it just means that you need to give up on using XIB files from your language and you probably wont get syntax highlighting and intellisense. But if you are porting code from another language, you probably dont need it. This also means that you would probably have to build your assembly independently and just reference that from your C# project.
So you compile with FoobarCompiler your code into a .dll and then reference in your main C# project.
The language runtime component only matters for languages that generate calls into a set of supporting routines at runtime and those routines are not part of the base class libraries (BCL). C# makes a few of those calls, but they are part of the BCL.
If your compiler generates calls to a supporting runtime that is not part of the BCL, you need to rebuild your compiler runtime using the Mono Mobile Profile. This is required since most runtimes target a desktop edition of the BCL. There are many other API profiles available, like Silverlight, Mono Mobile, Compact Framework and Micro Framework.
Once you have your runtime compiled with our core assemblies, then you are done
If you had read the MonoTouch FAQ, you would have noticed that it currently supports only C# and no other CLR languages.
Binaries for the Scala.NET library and the compiler can be obtained via SVN, in the bin folder of the preview:
svn co http://lampsvn.epfl.ch/svn-repos/scala/scala-experimental/trunk/bootstrap
Bootstrapping has been an important step, and ongoing work will add support for missing features (CLR generics, etc). All that will be done.
For now we're testing Scala.NET on Microsoft implementations only, but we would like our compiler to be useful for as many profiles and runtime implementations as possible.
A survivor's report on using Scala.NET on XNA at http://www.srtsolutions.com/tag/scala
Miguel Garcia
http://lamp.epfl.ch/~magarcia/ScalaNET/