For any new apps or updates, Apple requires you to use a Launch Screen Storyboard now instead of Launch Images (I'm not even sure if Apple has specified launch image sizes/names for their newest devices, since the images aren't supported anymore).  Launch Screen Storyboards should avoid having this issue in the future, since it automatically sizes things correctly for any resolution and doesn't require those images to determine resolution support.  You do need Xcode to generate the Storyboard, which will put any graphics into your Assets.car along with your app icons, and create a separate directory with Storyboard information.   Here's a brief tutorial from the Starling wiki on creating a Storyboard, I'd recommend setting this up in the same Xcode project that generates your app icons, so all the assets are packaged into the same Assets.car: https://wiki.starling-framework.org/manual/ios_launch_images#using_launchscreenstoryboard ... View more

I'd recommend sticking with two separate APKs for now, Harman considers their packaging for the bundle to still be in an experimental state, and it currently has issues if your app uses certain ANEs. ... View more

I don't think so, it sure would be nice though!     I've just watched the Adobe-Runtime-Support github so I get emailed whenever somebody posts there, so when I start seeing a bunch of issues being closed at once I check to see if there's a new version up that fixed those things 🙂 ... View more

Have you updated to the recent 33.1.1.190?  This bug is listed as fixed in the release notes for that newest version: https://airsdk.harman.com/release_notes     ... View more

Unfortunately I don't think Adobe has ever updated the AIR runtime to be compatible with Catalina, there's either an issue with 64-bit compatibility or app signing (or both).   App developers can choose to create an application that has the AIR runtime bundled and built-in (instead of requiring a separate download), and those CAN in theory be made to work on Catalina, but if they're relying on Adobe's separate download of Adobe AIR unfortunately that likely won't function on Catalina. ... View more

Adobe's documentation is a bit out-of-date, Apple requires all apps to include LaunchScreen Storyboards and icons provided in Assets.car now (both normally generated using Xcode on a Mac).  AIR unfortunately can't natively do this anymore, here are some tutorials on setting these up:   https://airnativeextensions.github.io/tutorials/ios-icons-assets-car https://airnativeextensions.github.io/tutorials/ios-launchscreens   Once these are set up, it should work correctly without letterboxing the app. ... View more

Harman's AIR 33.1.1.98 does already use the iOS 13 SDK, are you sure it was added to Animate correctly and used for the iOS build you submitted?  You can double-check the ipa file you submitted by checking the Info.plist inside of it (if you're using Windows you may want to make a copy of the .ipa and change it to .zip so you can easily explore the files inside).  For a recent 33.1 build I'm seeing DTPlatformVersion as 13.2 for the SDK version, and near the bottom for CTAirSdkVersion you can see which version of AIR compiled that ipa, to make sure it shows 33.1.1.98.   Also there are some complications with building iOS apps if you're using a Mac with Catalina (Macs pre-Catalina or Windows don't have the same issues), you can read more about those issues in Harman's Release Notes. ... View more

What are you trying to accomplish with your ExternalInterface calls?  In the example you've shown, you're checking window.location, which makes sense for a web application that's running in a browser window, but AIR generates standalone applications (exe, ipa, etc.) which don't run in a browser window, so there wouldn't be anything to communicate with. ... View more

Great advice from Lars_Laborious above, just wanted to add that GPU render mode can also be great for vector content, so if you're using vector graphics for your animations you could always try switching it to GPU mode first and see if the performance improves for you with just that, before converting all of your clips to bitmaps (or selectively changing your more complex graphics to bitmaps as needed).   Also, be sure that you fully remove the Blend Modes from the clips in Animate for the best performance.  AIR won't be able to apply the blend modes anyway, but it does still cache the clip as a Bitmap when a blend mode is applied, which can lead to a performance drop if there's animation within that clip (re-caching that bitmap every frame). ... View more

I'm guessing you're trying to do the steps shown here? https://community.adobe.com/t5/air/adobe-air-error-message-macosx-catalina/m-p/10753580#M55837   If that's the case, it looks you may have copied and pasted the code all as one line in the terminal instead of two.  First type "cd /Library/Frameworks", then hit return, then do the second line that starts with sudo.   ... View more

That's correct, you'll need to add Launch Images for apps to appear fullscreen on iOS devices.  Ideally you would want to include images for every resolution/device your app will support, the full total is around 20 or more right now.  Here's a list of the current names and sizes which seems to be accurate: https://wiki.starling-framework.org/manual/ios_launch_images   PNGs created in Photoshop or Illustrator would be fine.  Depending on how you're building/packaging your app, you'll want to make sure all of these images are included in the final ipa generated, at the same root level as your application swf and xml -- so if you're using Animate, make sure each launch image is added to your "Included files" alongside the swf and xml, or if you're using the command line adt, make sure you type all of the launch image filenames into the package command.   Soon Apple will require that you use Launch Storyboards instead of Launch Images for all app submissions, at the link above you can see the workflow for that as well if you'd rather go that route now (it requires a Mac with Xcode). ... View more

This may be related to an issue with devices running iOS 13, Harman has been trying to solve this for AIR 33, you can follow their progress in their bug tracker here: https://github.com/Gamua/Adobe-Runtime-Support/issues/112   If you're only trying to install your AIR 32 app on your device (and not necessarily use the debugger), you may want to use the old version of iTunes that Apple created for businesses to deploy apps to their devices: https://support.apple.com/en-us/HT208079   We've been using that iTunes version for installing test versions instead of using Animate/adt install options, which works fine on all of our iOS devices. ... View more

I'm not seeing this on Windows, I'm guessing this is happening on MacOS?   I'd recommend posting it on the Issues github page that Harman checks: https://github.com/Gamua/Adobe-Runtime-Support/issues   I remember a while back Apple enforced the elements in that array being integers instead of strings, and Adobe did a fix for AIR where you still specify them as strings, but ADT would automatically switch these to integers in the Info.plist. Maybe now that Harman is starting to work on ADT for Catalina they accidentally removed Adobe's fix for that. Incidentally ADT doesn't allow you to actually specify integers for those -- you'll get that same error on Windows if you use integer directly instead of string -- but maybe Harman now expects you to use integer instead of string on MacOS?  Might be worth a shot trying (and posting the error to the github either way since it should ideally still allow the old method as well.) ... View more

Is there a reason you're using AIR 33 already for an iOS build?  I don't believe Harman has done anything for iOS yet in AIR 33 since they're still only focused on Android with the other platforms being updated in a future release.  The only thing they may have done for iOS is trying to fix compiling issues on a Mac if you upgraded to Catalina already.    We're still using AIR 32 for our iOS releases until Harman officially starts supporting it, and haven't had any issues with sticking with 32 for now.  If you do switch to AIR 33 for any releases, like Douglas mentioned you will need to use 32.0 in the app descriptor, they have information about this and a few other compiler workarounds in the Release Notes documentation. ... View more

We recently migrated from the Milkman ANE over to Distriqt's for our upcoming release, you can check out their ANE here: https://airnativeextensions.com/extension/com.distriqt.InAppBilling     ... View more

You might be able to use the older AIR 32 and target Android SDK 28, it wasn't actually designed for it but others have mentioned having luck with it and not seeing too many issues (aside from some problems with the back button).  In your application XML you would have to set in your manifest:   <uses-sdk android:minSdkVersion="19" android:targetSdkVersion="28" />   Or if you wanted to switch to Harman's AIR 33, it's built to support SDK 28.  To get rid of that splash screen on app start-up, you'd have to purchase a paid commercial license from Harman, you can get the process started by emailing them at Adobe.Support@harman.com and letting them know which tier you'll need. ... View more

I haven't tried with PDFs before, but I do have an app that saves images to the applicationStorageDirectory using File and FileStream, then I can load the image in later using the "app-storage:/" URL scheme in a URLRequest.  I believe that's based on the File's url, rather than the nativePath. Are you trying to open the PDF from within the same app that created/saved the PDF?  Or trying to access it outside of this app?  On mobile devices I don't believe you can actually browse to the applicationStorageDirectory since it's local to the app itself and can't be accessed by anything else. ... View more

juvelez  wrote But the other tiers are so expensive that is more viable to port some commercial apps to a near technology like Haxe and the new ones using a more profitable SDKs. I guess it all depends on your specific needs, though personally I don't think the pricing is expensive especially if you have a portfolio of existing apps that you need to continue supporting.  We have a bunch of games developed in AIR already, and the costs involved in porting those to some other technology would be astronomical compared to the licensing fee Harman is asking for, especially since with Harman you're just paying for the tools and it's not on an app-by-app basis. juvelez  wrote What I mean is, it's a harsh and costly transition, in fact, there isn't a transition at all, we was caught in the middle of a technology change forced by Google and Apple, and they are taking advantage from that apparently just to win money It was definitely terrible timing for us users that Adobe decided to do this right before the Google 64-bit deadline, especially when Adobe knew about this requirement for over a year and never bothered working towards it.  It sounds to me like Adobe was just planning on giving up and dropping AIR completely, until Harman came in to try to pick it up before that happened.  It makes sense that they'd have to start charging for it though, since Adobe was theoretically subsidizing development on AIR with their CC/Animate subscriptions, and Harman wouldn't have that to fall back on to pay their own development team.  At least Google pushed back the deadline for AIR apps and 64-bit though, so anyone who's not yet comfortable paying has a little breathing room. ... View more

I would change your "android" section to look like this instead (changes in bold): <android> <manifestAdditions> <![CDATA[ <manifest> <uses-permission android:name="android.permission.INTERNET"/> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> <uses-permission android:name="android.permission.READ_PHONE_STATE"/> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/> <uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/> <application> <meta-data android:name="android.max_aspect" android:value="2.16" /> </application> </manifest> ]]> </manifestAdditions> </android> ... View more

I'm pretty sure that Android Q crash bug was fixed by Google starting in Beta 3, where those new requirements now only apply if your targetSdkVersion is set to 29, and apps set to a lower targetSdkVersion will follow the old rules and requirements instead.  I don't have a device with the Android Q Beta on it myself though to double-check, if anyone does and could confirm that would be great! Also noticed this in their documentation which seems to mention the fix (in bold): Shared objects cannot contain text relocations Android 6.0 (API level 23) disallowed use of text relocations in shared objects. Code must be loaded as-is, and must not be modified. This change improves app load times and security. In Android Q Beta 1 and 2, SELinux enforces this restriction on apps targeting Android 8.0 (API level 26) and higher. Starting in Android Q Beta 3, the restriction is enforced on apps targeting Android Q (API level 29) and higher. If these apps continue to use shared objects that contain text relocations, they are at high risk of breaking. ... View more

Yeah I agree it doesn't make sense to compare them, though to be fair AIR is only more expensive than Unity in certain scenarios.  If you're making < 50K they're the same price, and if you're making > 200K AIR is cheaper than Unity. It's in the 50-200K range that AIR can be more expensive, though I'm sure with Unity development you're going to need more seats overall for everyone on the team, whereas with AIR you'll need seats for anyone compiling but your artists and animators likely won't need seats. Overall it's up to each company/individual to decide the right tool for each project, and if you choose AIR for a project then the seats are just the cost of doing business, the same as if I'm going to be spending $600/year for Adobe CC for an artist, $500/year for IntelliJ IDEA for a programmer, $1500/year for a Unity seat, etc.  I get why people (including Harman) would compare AIR to Unity because of some use overlap, but they're different tools and personally I'm not going to worry about whether Product X has more features than Product Y just because it may cost more. ... View more

It's still actually only one seat of Unity for $125 -- you do get 3 seats of "Unity Teams Advanced" included which is a completely different product.  Aside from that though, I agree with you that AIR shouldn't be compared with Unity since they're not really in the same category, and yeah that's a tough sell for attracting new developers if they're looking at the two side by side.  In our case the AIR pricing is fine for allowing us to update/maintain our existing apps, and to continue with some new apps that use the same pipeline, but getting support from new developers vs. the built-in customer base of legacy developers will be the real challenge here. ... View more

Right now you need to email them or sign up for updates on their website to get added to the mailing list, though I'm not sure if the attachments with the updated pricing are included with each email they send out.  Here are the basic details though: Free Tier - includes an injected splash screen at startup - no annual fee - can only use if your total income < $50K/year Basic - $199 annual fee - if your total income < $100K/year Professional - $799 annual fee - if your total income < $500K/year Enterprise - $1199 annual fee - no income limits This is pricing per seat to use the AIR Developer Tool to package apps, and the income thresholds are your total income for the previous 12 months. ... View more

I understand where you're coming from with the idea of "if they're charging what Unity charges, it must do everything that Unity can do", but I do think AIR is its own beast which has its own strengths that are different from Unity (although of course there is a lot of overlap), and it doesn't necessarily need to follow exactly in its footsteps. There are so many varied use cases for AIR, I'm sure it's tricky for Harman (or Adobe previously) to decide what to implement or focus on for roadmaps.  Some developers are using it for UI-based apps, some for games, some using Starling, some using GPU-accelerated vector graphics, etc., so what would benefit one group may not benefit some others.  Personally I don't have any need myself for a 2D/3D/GUI Editor, and that sounds like it would be a HUGE undertaking to basically make a replacement for Adobe Animate with the addition of 3D features which Animate never had.  I'm also not as concerned about having all native features being added to the core of AIR, for all of the ANEs we've used the pricing has been very reasonable and don't require ongoing subscriptions.  I'd much rather see them spend time on adding new features/updates to the AIR runtime and fixing bugs that have been hanging around for years, and keeping up with the moving target of mobile app store requirements.  Though of course there are others using AIR in different ways who may have different needs. ... View more

Strange, I've never defined any Entitlements specifically for our apps (the aps-environment only applies to Push Notifications which we don't use), the app provisioning profiles contain their own Entitlement information that gets added to your app depending on which profile you select with the build. When you say you'd change "production" to "development" for your development profile, that key only applies to how your push notifications are running and has nothing to do with the app itself, so I'm guessing you're also switching between an app store .mobileprovision file and a development .mobileprovision file when you're testing on device too? ... View more

That's odd, I just generated some new provisioning profiles and everything is working fine, they look identical in structure to the profiles I generated a few months ago and to ones I generated a few years ago. For all of the errors you're getting, that sounds exactly like what would happen if you were using a Development profile instead of an App Store profile --- a Development profile does not contain the beta-reports-active entitlement, and a Development profile has get-task-allow set to true. Here's one more thing you could try to make sure the mobileprovision file you're using is correct -- open up the App Store ipa/app that you generated, and find the embedded.mobileprovision in the Payload folder which will be the exact provisioning profile the app is using.  Copy that out of there, and then run the Terminal command on it to see exactly what is listed inside the app.  An App Store profile should have beta-reports-active set to true, and get-task-allow set to false.  A development profile will have get-task-allow set to true, it won't have a beta-reports-active key, and it will also have a ProvisionedDevices key. ... View more

I believe get-task-allow is automatically added to development provisioning profiles, and are not added to distribution provisioning profiles.  Are you sure you didn't accidentally try building an App Store distribution build with your development profile instead of your distribution profile? If you have a Mac, you can also check to see what Entitlements are included in your provisioning profile with this Terminal command: security cms -D -i /path/to/your/profile.mobileprovision I just checked on my development profiles and they do have get-task-allow set to true, while my adhoc and appstore distribution profiles have get-task-allow set to false, so it might be worth checking the profile you're using for the App Store build to make sure it didn't get swapped for a development one. ... View more