I'd say that's a good decision, those are the big two stores, they're the only two we've ever released on for Android as well.  You can generally just use your Google Play apk build when submitting to Amazon, unless you're using Google-specific features in which case you might need some adjustments (Amazon has their own AIR ANE for in-app purchases for example).  Review process is pretty smooth for Amazon and generally takes 24 hours for us.  For Google Play we typically do an alpha release first because we're testing in-app purchases, but when we promote that to production it's instantly released.  Maybe someone at Google reviews the app between alpha and production releases, but there's no actual process for reviews, you don't have to submit it for approval first or anything. ... View more

Chris, is there a list of related APIs besides getTimer() that are affected by the Spectre/Meltdown mitigation?  It would be really helpful for developers to know what exactly has changed (and the speed impacts for each), so we have some reference of what we might need to update and avoid when we're seeing large performance issues in our projects.  I checked the release notes, but it only lists shareable ByteArrays under the Spectre/Meltdown notes, and doesn't mention getTimer() or anything else that might be impacted. ... View more

Yeah, like Douglas said there's really not an actual review process for Google Play.  They claim that people will review the apps, but usually when I publish a version to production it goes live to the store within 30 seconds or so, so I doubt anyone is actually reviewing anything that often. ... View more

I followed the steps in this Adobe doc, above halfway down the page is a "Signing apps for Android" section that explains the requirements and shows how to generate a certificate on the command line using adt: Signing Adobe AIR applications | Adobe Developer Connection Looks like it also has Flash Builder instructions if you don't want to use the command line.  I used the adt method myself and have been using that same self-signed cert for years with no problems. ... View more

They've also deprecated it on mobile for iOS 12: What’s New in iOS - Apple Developer ... View more

They've also announced deprecation of OpenGL ES for iOS 12: https://developer.apple.com/ios/whats-new/#deprecationofopengles Does anyone have information on how "GPU" render mode is handled, and if this will also be affected like Stage3D by these deprecations?  I'm not too familiar with what GPU render mode is doing under the hood. ... View more

For the App Store release, I believe from now on you can only use the AIR 30 beta, or you can attempt to use AIR 29.0.0.122 (if you manually add a few location keys to your InfoAdditions section to get around other rejection issues).  Apple is rejecting older versions of AIR for that non-public API warning you mentioned, which was fixed in 29.0.0.122 and in AIR 30. Other developers have mentioned that their apps have been released successfully even though they got that "Certificate Expired" warning, though it's not clear when that will change from being only a warning to a full rejection. ... View more

This isn't quite the same thing you're talking about, but there are some tutorials for modifying the AIR SDK to get some sort of splash image like this one from distriqt: AIR Native Extension Tutorials by airnativeextensions Unfortunately you have to make these changes each time you download a new AIR SDK version, and all of the apps you publish will use this same style of splash since there's no way to do this on an app-by-app basis in the manifest. ... View more

Instead of new ApplicationDomain(), for AIR apps you need to reference the app's current application domain like this: context.applicationDomain = ApplicationDomain.currentDomain; Since you mentioned accessing the stage, just wanted to also make sure you were aware that remote SWFs can't run any ActionScript in apps on iOS.  There are some packaging workarounds if you're loading local external SWFs and need to use ActionScript, but as far as I know remote SWFs still aren't allowed to use any ActionScript byte code. ... View more

Did you make any changes to android:targetSdkVersion in the app XML for the AIR 30 build?  Seems strange that AIR 29 would be okay and AIR 30 wouldn't, since they both seem to use the same Android SDK for building apps. ... View more

It looks like MODE_WORLD_READABLE was used for saving files (and possibly saving photos to camera roll), but this was deprecated and removed from the Android SDK a while back.  I'm not seeing any problems myself with AIR 30 and file saving using FileStream.writeBytes, does your app do any kind of file writing or creation using a different method?  Or are you using any older ANEs that deal with files, that maybe still used the older SDK where MODE_WORLD_READABLE was still allowed? ... View more

JulianDMG​ You're right that the way you're supposed to target newer devices is by changing MinimumOSVersion, but the Q&A and other Apple documentation also says that this only works as long as you do not make any changes to UIRequiredDeviceCapabilities when you do that.  The 64-bit-only builds from the AIR 30 beta were making changes to UIRequiredDeviceCapabilities automatically, so even if we set MinimumOSVersion to 11, it still wouldn't be allowed as an update since you can't change UIRequiredDeviceCapabilties after release for any reason.  It's bizarre since the MinimumOSVersion would limit it to 64-bit-only devices anyway, but unless they change their policies in the future you just can't touch that UIRequiredDeviceCapabilities key. Thankfully Chris announced that they'll be restoring 32+64-bit builds in AIR 30 in an upcoming beta update! Re: AIR 30 dropping support for 32-bit in iOS apps So hopefully we won't have to worry about this again until Apple makes the requirement themselves, in which case I'm assuming they'd change their update policies. ... View more

Chris, thanks so much for listening to our concerns and taking action to revert these changes, it really means a lot that you and the AIR team listen to our feedback.  This is a huge relief knowing we can continue with hybrid apps and will be able to keep updating our existing apps with AIR 30.  Thanks for the help and for all the great work you do! ... View more

https://forums.adobe.com/people/Fr%C3%A9d%C3%A9ric+C.  wrote AIR 30 release notes say that Android apps remain unaffected by this change. Only iOS apps are. I just double-checked an Android build with AIR 30 and can confirm it's unaffected, still supports 32-bit with the armeabi-v7a platform, with the exact same number of supported Android devices between AIR 29 and AIR 30. ... View more

I agree it doesn't make sense, but their Q&A mentions this in multiple spots: Important: Because you can't add UIRequiredDeviceCapabilities restrictions after an app is in the store, be sure to plan ahead by choosing requirements you will be comfortable supporting indefinitely going forward. Important: Do not modify the UIRequiredDeviceCapabilities info.plist key when requiring a newer iOS version. For example, if your app is no longer built with armv6 , you should not add armv7 to your UIRequiredDeviceCapabilities . (I'm assuming armv7 -> arm64 applies to that last case as well) I don't know of any exceptions to this policy, and was hoping Adobe could enlighten us on if they have additional info from Apple about this, since they'd be the most likely to have this information from the source, and have hopefully checked with Apple about this to confirm before deciding to drop support.  It would be nice to know for certain whether there are exceptions (meaning AIR 30 can be used for updates) or if there are not (meaning AIR 30 can not be used).  Looking through all of Apple's documentation on UIRequiredDeviceCapabilities and the related Technical Q&As, I haven't seen anything that would allow for any exceptions, just repeatedly stating that you can not ever change those values in an update for any reason, and must only change MinimumOSVersion.  Hoping Adobe can set the record straight for everyone, so we're not second-guessing whether Apple really means what it says in all of its documents. ... View more

Based on that other thread, developers were saying they were getting that error even when their apps do not use locations services at all.  I was under the impression it was another service that Adobe was enabling by default even though all apps don't use it (like the issue with microphone access being enabled by Adobe by default years ago), though I haven't seen the error first-hand yet myself (haven't tried to update anything recently). ... View more

OMA2k  wrote I'm asking this because iOS 11 requires "arm64" devices anyway (it doesn't work in "armv7"), and I don't think Apple will forbid ALL iOS developers from updating their previously hybrid apps to iOS 11 (requiring them to create new apps with different app bundle identifiers), won't it? Also, Apple says that you can remove device support if you "target a newer version of iOS that requires a newer device". Wouldn't that be an exception to the "Do not modify the UIRequiredDeviceCapabilities info.plist key when requiring a newer iOS version" rule? Thank you for your comments. From what I've seen in Apple's policies and Q&A, they want you to only change MinimumOSVersion to 11 in order to limit it to iOS 11 devices, and to not change UIRequiredDeviceCapabilties at all in the process.  Like you said, iOS 11 only runs on arm64 devices anyway so you're effectively limiting it, but by Apple's policies you can't explicitly change your device requirements, only that minimum iOS version. For what it's worth, AIR 28 and 29 already upgraded to the iOS 11 SDK so they already do have the ability to support the newer SDK functions if you have an ANE that uses iOS 11-exclusive features, so using AIR 30 and 64-bit-only is not a requirement to get the features of iOS 11 (you'd just have to gracefully handle older devices not supporting certain APIs, etc. like most ANEs require). ... View more

Glad to hear your update made it through, it looks like I may have been mistaken about the date the issue started, April 1st was the _IOPSCopyPowerSourcesList issue but the location issue started cropping up around April 26th.  For anyone interested, Page 4 of this topic discusses the issue with Apple's rejections from accessing privacy-sensitive data with the location services in AIR 29 (and the temporary workaround of adding a bogus explanation key to our apps while Adobe still accesses these services): Adobe Air SDK 29 is not accepted by Apple ... View more

One outstanding issue with AIR 29 I'm seeing is Apple rejecting apps in AIR 29 that don't include NSLocationAlwaysUsageDescription and NSLocationWhenInUseUsageDescription keys.  Yes, we can include the keys ourselves ourselves for now with a nonsense description of "Required by Adobe SDK for some reason".  That's a temporary solution (maybe for weeks? months?), and Apple reviewers will eventually crack down and want to know why Adobe is accessing location APIs when our apps aren't using them, and will require the API access to be removed from the app instead of just adding a bogus text string as a reason.  I'm sure Adobe will eventually fix it for AIR 30, but AIR 29 will be left as-is. For one of our own apps we squeaked by with an update on March 28th before this new restriction went into affect on April 1st, but AIR 29.0.0.122 builds have been hit with this rejection since then. ... View more

If you unzip the ipa created by AIR 30, it has "arm64" as a required device capability for the app to run.  These devices do not support arm64 architecture and can not run apps created by AIR 30 right now: iPad 2 iPad 3 iPad 4 iPad Mini iPhone 5 iPhone 5C I've attempted to install an AIR 30 on all 4 of those iPads listed, and I get errors on all of them that it is not supported. On Apple's Device Compatibility page you can see in Table 1-7 (and 1-6 and 1-5) that these devices do not support arm64: https://developer.apple.com/library/content/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/DeviceCompa… ... View more

https://forums.adobe.com/people/Colin+Holgate  wrote For those of you who have talked about having a lot of customers using the 32 bit part of your existing 32+64 bit apps, what iOS version are they running? If it is iOS 8 or earlier, how will you update the app in a way that complies with the new iPhone X requirements? Here's a sample of what I'm seeing for our installs in the last 90 days across multiple apps and what OS the users are running: Papa's Freezeria HD:  64.25% iOS 11 15.51% iOS 10 20.24% iOS 9 Papa's Pizzeria HD: 69.3% iOS 11 15.39% iOS 10 15.31% iOS 9 Papa's Hot Doggeria HD: 72.16% iOS 11 12.77% iOS 10 15.07% iOS 9 (iOS 8 is negligible, just one or two units per app) This is a sampling of apps that were released years ago and apps released more recently, but these are all installs that were made within the last 90 days.  These are iPad figures, so I'd imagine the large volume of iOS 9 is from legacy devices that can't upgrade beyond iOS 9.3.5.  Hard to say with iOS 10, some may be iPad 4 locked into 10 and some may be newer devices and haven't updated their OS yet. ... View more

https://forums.adobe.com/people/Josh+Tynjala  wrote Does this indicate that a current universal app that supports both 32-bit and 64-bit architectures can be updated to 64-bit only without changing the bundle ID as long as it targets a version of iOS that doesn't support 32-bit devices anymore? If that's the case, users with old 32-bit devices would be stuck on an old version, but users with 64-bit devices would still get updates to the existing app. Right? According to Apple in their Technical Q&A 1623, that's only true if you don't make any changes at all to UIRequiredDeviceCapabilities between versions: Important: Do not modify the UIRequiredDeviceCapabilities info.plist key when requiring a newer iOS version. Since AIR 30 has a completely different set of UIRequiredDeviceCapabilities ("arm64" in AIR 30, vs. "armv7"+"opengles_2" in AIR 29 builds), our app updates will likely be rejected even if we set the MinimumOSVersion to 11. ... View more

I'd love if it were as simple as that, but AIR 29 has a number of new issues with Apple's submission process that Adobe decided not to fix, and are only updating to fix those issues in the AIR 30 Beta.  Their latest build of AIR 29 also broke some features in the process while they were getting it to comply with the first round of submission issues, and I'm guessing they also won't be going back to fix those in AIR 29, since they're listed as fixes in the AIR 30 release notes and they keep directing users to download AIR 30 instead.  If they had left us with a stable usable release of AIR 29 it wouldn't be as big of a deal, but it's a bit of a mess at the moment. ... View more

I agree that point will come in the future, but personally I think it wouldn't be as large of an issue for us if it was affecting ALL apps available on the App Store at the same time (by changes from Apple), versus a change that Adobe is making but other toolsets and engines are not currently making.  It would be much easier to explain to users that all apps they could possibly want are 64-bit only now, rather than explaining that our apps are now 64-bit-only because of the toolset we chose, while competing apps are still working just fine because those toolsets decided to wait until Apple pulls the plug themselves, however further in the future that might be. Presumably Apple would communicate things directly to the affected users (through the App Store app itself?) that they'll no longer be able to download any new or updated apps when that time comes.  I'm not sure end users necessarily realize how antiquated their devices are, and right now they may just know that they can't get iOS 11, but they can still get Minecraft and Five Nights at Freddy's and Netflix and that's all they're really worried about. ... View more

YES, AIR 30 does modify UIRequiredDeviceCapabilities, which is in violation of Apple's policies outlined in QA1623.  It's all there in plain text that this is not allowed. ... View more

ASWC  wrote Why a "serious issue"? We can publish our new updated 64bits only as new apps which is something many have had to do before for number of reasons anyway. It's annoying sure but really serious issue? I am shocked that you think developers can abandon their existing user base so easily, especially if these are paying users who purchased our app literally yesterday, and can now no longer receive updates to the app they just paid for because we've moved to a new bundle ID.  It's a serious issue on the business side of things when you're running a studio with paying customers, you can discount it as a technical issue if you like but that is besides the point.  We've never had to release a completely different app to get around issues like this before, and we've never had to abandon paying customers in the process. I can't speak for the ramifications for freelance developers who are focused on their client's needs for a specific project, but our studio releases a number of paid apps in the App Store, and this change will affect literally hundreds of thousands of our own paying customers. ... View more

I apologize, some of that reply was also towards zwetan_uk's message, didn't mean to say you were claiming apps could or should be 32-bit-only.  Didn't mean to imply Adobe was involved in those decisions, I just meant that Adobe did change AIR's functionality to only build 32+64-bit hybrid apps (which Apple said was required, so that's why Adobe did it, as you mentioned).  zwetan_uk keeps bringing up that developers shouldn't be building 32-bit-only apps anymore, and I was merely pointing out that would be impossible anyway (Apple said it wasn't allowed, and Adobe followed by making all builds 32+64-bit). ... View more

No need to get rude, I've seen a few people claiming that Apple has specifically announced that apps must be 64-bit-only for iOS (not talking about Mac here), and I'd like to see that Apple has in fact specifically made that statement, or if people are just saying this because it supports their argument.  I'm sure the trajectory is that Apple will eventually drop support for more and more devices, but I haven't seen them announce support will be dropped at a specific point (next week, next month, next year).  Yes, eventually they will fully drop support for 32-bit devices, just like eventually they will fully drop support for iPhone 7 and 8 and X years from now, but that doesn't mean I'm going to stop supporting them before I'm required to. ... View more

zwetan_uk  wrote It is useless to keep supporting hybrid (32-bit + 64-bit) apps Why? Because Apple only allow 64-bit devices to get app updates This is wildly untrue, and as an AIR developer I'm shocked that you don't realize this is not true.  I just updated a hybrid app weeks ago, and 32-bit devices were able to get the app update as well as 64-bit devices.  It was a hybrid 32+64-bit app, and well, that's how they work by design. ASWC​ can you point us to specific documentation from Apple that claims all apps for iOS will need to be 64-bit-only at some point?  All zwetan_uk has shared are articles from 2015 saying you must support 64-bit as well as 32-bit together in the same app, which AIR has been doing since 2015.  Nobody is arguing that we need to support 32-bit-only apps, both Adobe and Apple made that impossible years ago. ... View more

As long as the assets folder was included when building the app, this seems to be working for me in another app: var filepath:String = "assets/music.mp3"; var mySound:Sound = new Sound(); mySound.addEventListener(IOErrorEvent.IO_ERROR, onMusicError); mySound.addEventListener(Event.COMPLETE, onMusicLoaded); mySound.load(new URLRequest(filepath)); And then calling mySound.play() in the onMusicLoaded function. ... View more