There is an an AIR app which is being maintained, and for the time being, things were alright. Up until Dec. 08 when AIR update 20.0 came in, leaving an error message
"The required native extension is missing for this application. Try re-installing or contacting the publisher for assistance".
A lot of people have been seeing same, so it must be a common problem - that AIR update broke down all native extensions, like:
https://scratch.mit.edu/discuss/topic/172434/
https://support.magplus.com/hc/communities/public/questions/207651297-Adobe-AIR-The-required-native-extension-is-missing
etc. etc.
Is there any definite fix, or all we have to do is to sit and wait for Adobe to issue a fixed version? People suggests downgrading to version 19.0 but it seems impractical for any massively used app, most users will simply give up on it rather than downgrade.
Air 20 on OS-X made the jump to 64-bit (Windows 64-bit will be released next) and thus any ANEs would need to be compile for ARCH x86_64 and the Air application re-packaged and published to work on the Air 20 runtime.
If you need both runtimes you can install Air 19, rename name the installer to something else, i.e. "Adobe AIR Application Installer 19.app" and then install Air 20...
AIR 64-bit on Mac OS X
The AIR shared runtime and SDK are now fully 64-bit on OSX!
With AIR 20, all Mac AIR applications will be 64-bit compatible.
If you require 32-bit compatibility for OSX, please continue to use AIR 19 to create captive runtime applications.
Re: https://forums.adobe.com/thread/2051806
Related
The installer runs for a while and many files get installed but it hangs. There is a choice of installing the GNAT compiler tool chain, SPARK tool set and GPS development environment. I've tried it with just the compiler and with all three. Both ways do not complete. Too abort the installer I need to do a force quit.
I have the latest update to MAC OS X installed, plenty of free disk space and memory. I'm trying to install it on MAC Book Pro with touch bar.
I had this issue, and it came up on the GNAT-OSX mailing list, 10 June. (Firefox complains about that site’s security configuration, by the way).
The solution (for Pascal on the list, and for me) was to install with the 'detailed view' off.
I have difficulties installing the latest version of Adobe Flash Player (14.0.0.125) on my Mac OS X 10.9.3 (Mavericks). Every time I do so, it fails at 90% with the following error message.
Error: Unable to proceed with the installation
When I go to troubleshoot the problem, I find that I have version 13.0.0.214 of Flash Player installed on my system, and that the (alleged) latest version (for Mac OS X 10.6, 10.7 and 10.8) is 13.0.0.201 (see following URL).
http://helpx.adobe.com/flash-player/kb/installation-problems-flash-player-rvm.html
Further research has revealed that the latest version of Flash Player (for Mac OS X 10.6, 10.7, 10.8 and 10.9) is 14.0.0.125 (see following URL).
http://helpx.adobe.com/flash-player/kb/installation-problems-flash-player-mac.html#main-pars_heading_7
This is not the first time I have experienced problems upgrading Adobe Flash Player. I experienced a similar problem before upgrading to Mac OS X 10.9 except with different version numbers of the same software. That is, the version that was installed was greater than the version that was downloaded. Note that I did not experience this problem with prior versions of the OS (i.e. Mac OS X 10.6 and 10.7).
This time I went one step further and used a different default browser to locate, download and install (what I presumed was the latest version of) Flash Player. No difference....
My question is, why does my default browser point to an older version of the installation software, and how can I resolve this? Also, correct me if I am wrong but, the reason I have a 'later' version of the software (that is, version 13.0.0.214) is due to the OS upgrade? I do not recall ever upgrading Adobe Flash Player....
Not sure whether or not this is relevant, but I also have Adobe Creative Suite 5 installed on my system (which was also successfully upgraded during all OS upgrades).
UPDATE: Did a bit more searching on the Adobe forums and found a link to a previous version of Adobe Flash Player version 13.0.0.223. Although not the latest version, I have successfully installed it. That is, after I uninstalled the older version of Flash Player. The problem I experienced sounds almost identical to this installation problem.
I am still, however, experiencing the same problem when upgrading to version 14 of Flash Player (even through System Preferences). Seems to be a problem with the installer, and not my system configuration since, to resolve this problem, I uninstall Flash Player (like before) and successfully installed Flash Player version 14 OS X, which I found and downloaded from the same web site.
I can't find information on what are the system requirements for Mac for the mobile add-on for Delphi XE4 (Professional).
My understanding is that XCode is still required to sign the app binary and to deploy it on a test device and/or App Store.
Our Mac is so old that the minimum requirement of OSX for the latest XCode won't even install.
I'd like to know if we need to have the Mac upgraded to accomodate this.
Ok - found the answer: https://www.embarcadero.com/products/rad-studio/rad-studio-data-sheet.pdf second page:
PC running Windows connected with an Intel-based Mac, with 2 GB RAM
or more, running OS X
10.8 (Mountain Lion) or 10.7 (Lion) over a local area network using a SSH, VNC or Windows file sharing solution
Apologies & much appreciated if you've attempted to help me:
XCode will still be required, so of course your Mac system will have to be updated to be able to support it.
The documentation for XE3 will give you the minimums requirements for that version, and you should require XE4 to at least require those minimum requirements. As it doesn't seem your existing system meets those, you can probably be sure it won't support the requirements for XE4.
You can also contact Embarcadero Sales with pre-sales question, with the email address you'd expect (Sales at the companyname.com).
after reading the apple SDK guide
https://developer.apple.com/library/mac/#documentation/developertools/conceptual/cross_development/Overview/overview.html
I'm still confused of how to make the mac app backward compatible & how to test them properly
I have an app, I run it and tested it on Mountain Lion 10.8 without any problem, however I want to make this app backward compatible so that other users can run it on a mac 10.6 - 10.7 machine.
I have an apple developer id and I can download the old versions of 10.7 and 10.6, but the problem is, I have a 2011 macbook air which is currently running 10.8, and that's the only apple machine that I have. Can I test the 10.7 and 10.6 by using vmware or parallels?
in my project settings, I set the target deployment to 10.6 (as I want 10.6 users to run my app), but should I set my SDK to 10.8 or 10.7? if I set the SDK to 10.8 but having the target deployment set to 10.6, if I fix all the xcode warnings will it run successfully on 10.6??
from the SDK drop down, I can only set to 10.8 or 10.7, but 10.6 is missing, how do I fix that?
thanks in advance
I develop on a 10.8 box and support back to 10.5. Just a couple of months ago we dropped 10.4 PPC support, and I'm still cleaning out some of the 10.2-specific code. This may get a little rant-y, but I've been doing old versions for a long time. I have some opinions on the matter.
No matter what Apple says in their docs, if you want to support 10.6, then build with the 10.6 SDK. Do not rely on distribution target.
I have had this discussion with the Xcode engineers, and while they hold to Apple's party line that you should always build with the latest SDK, they also acknowledge that it's generally insane to do so. If you build against the 10.8 SDK and mark your deployment target at 10.6, you will get no warnings for using methods that do not exist on 10.6. The only way you will discover that you've used a nonexistent method is that it might give you strange bugs when run on 10.6. That's insane.
Remember, OS X doesn't crash when you send an unknown selector. It just aborts the current runloop. So the bugs are even harder to track down then on iOS, where it crashes the app.
Sure, you can do weak linking. Talk about dangerous.... Yes, there are a few times this is useful, but the compiler gives you no warning if you don't do it correctly. If I'm going to do weak linking like this, I go the other way, linking against the old SDK and copying the new function's prototype into my implementation. That way I have documentation of every function I think I'm going to weak-link.
Download the old SDKs and symlink them into your Xcode distribution.
Guard them jealously. Apple will try to delete them every time you upgrade Xcode. Make your own copies and stick them in /SDKs or somewhere else away from Xcode. I provide a script called fix-xcode to manage the symlinks automatically. Am I bitter at Apple for their relentless insistance on deleting my old SDKs? Yes, I am.
You can run 10.6 Server in a VM legally. You can run 10.7+ Desktop in a VM legally. These are good ways to test your code.
Or you can do what I do and have a small pile of old MacBooks each with two or three partitions on them that you reboot all the time.
Now that 10.7 comes from App Store, it's a little harder to make VMs. My strong recommendation is to snapshot your image immediately after install, and make a clean backup copy of it. You'll want to be able to clone that image from time to time when you need to get back to a "raw" machine.
Get in the habit of squirreling away SDKs as they come out. 10.8 will be old some day. You might as well make a copy now while it's easy.
Whether you support individual dot-releases or not, it can be very helpful to keep around the upgrade packages for individual dot releases. When you encounter customers running non-current releases, it's nice to be able to check whether an "unreproducible" bug in fact is easily reproducible on their specific version. Whether this is worth it or not depends heavily on your product and customers. It was a life-saver for me when 10.4.11 made major changes to WebKit during a dot release...
Invest in a small NAS or a big external USB drive (though I've had trouble with those failing when used extensively, so I prefer a RAID). You'll need the space. You want to hold onto lots of VMs and lots of SDKs and sometimes even old versions of Xcode.
Adding to Rob Napier's great in-depth answer:
To use an old SDK, put the SDK (or a symlink) to it here:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
With XCode 7.3 or later, you need you to open this file and change "MinimumSDKVersion" (otherwise XCode will refuse to use the old SDK):
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info.plist
You can install multiple versions of Mac OS on a single machine, booting between each.
The SDK should be the latest (10.8).
See 2.
One alternative to 1 that I've considered (I am in the same boat) is to create a Snow Leopard Hackintosh using an old PC and just installing Lion and Mountain Lion on my MBP.
You need to do these settings :
1.Set the Base SDK to Current version of Mac (ex. 10.7)
2.Set the Deployment SDK to older version (ex.1.4)
I just upgraded to Flash Builder 4.5, and I am trying to decide whether to install the Win or OS X version, since Adobe only allows you to install on one platform. I have been, up until now, developing an AS3 application using FB 4 under Windows 7 on my MacBook, and my Production Premium CS5 license is also for Windows (and I also do C++/Visual Studio development as well). Now I am going to try the iPhone Packager, to port my app to iOS. It seems to me that the workflow will be awkward once I cross-compile to Objective-C - as I will need to either reboot into OS X to compile and debug, or I will need to run FB 4.5 in a parallels session under OS X (though Adobe's activation freaked out when I tried this with Prod Prem CS4). The FB 4.5 / iOS workflow still requires xCode does it not? Is it foolish to even try this? Should I just bite the bullet and switch over to working in OSX?
Thanks!
I'd say it's better to keep things simple and stick with OSX. Constant switching among platforms is a sure productivity killer. Bite the bullet and stay on OSX - it will pay off on the mid run.
You're better off doing all of this in OSX