Update on Cordova apps on iOS 10

0 favourites
From the Asset Store
Creepy Sprite Font suitable font for your Dark/Horror/Halloween games.
  • Just a heads up. My game (https://itunes.apple.com/app/id1088622798) was working on iOS 9, and even iOS 10.0.1 (didn't get black screen or other issues surprisingly!) but the latest 10.0.2 now causes it to hang at the loading bar.

    I'm updating it and trying the latest C2 beta build, along with updated XDK & Cordova, was using 5.4.1 and now I see a new 6.2 is available, along with a 1.03 WKWebView plugin... will report back tomorrow on the testing.

  • Tested it with Cordova 6.2, WKWebView 1.1.0 (the latest) Cordova plugin in XDK.

    I am stuck at the loading progress bar, however, some launches it will go all the way and start the game up. Once into the game, it runs fine.

    I notice in the c2runtime.js there's this line:

    this.setImageSrc(img_, src_); // work around WKWebView problems


    if (this.runtime.isWKWebView)

    playMusicAsSoundWorkaround = true;

    Obviously a hack/workaround to a prior problem..

    Also the detection has changed somewhat?

    this.isWKWebView = !!(this.isiOS && this.isCordova && window["webkit"]);

    ^ I am going to test changing it to true;

    Because I don't need to check, the build uses WKWebView plugin and set for iOS9+ only.

    Edit: Changing that to true; causes it to hang at the start of loading again (most of the time, some launches work as before). Going to try setting it to false; ... I have a feeling some WKWebView work-around for prior iOS versions/Cordova is no longer required in iOS10+ or no longer functional. This isn't a detection of WKWebView problem!!

  • So, I've got about as far as I possibly can on my own trying to fix this issue, so I really need some help. I ask that we try and have a discussion about possible causes for these errors rather than filing a bug report, I've wasted days trying to fix this and if I hear the phrase 'file a bug report' I'll probably have a mental breakdown...anyway...

    My game (https://itunes.apple.com/gb/app/the-sla ... 1056603685) is unplayable using WKWebView. Before iOS10 was released, I got around this by compromising and using UIWebView. With iOS10 this is no longer an option as my game simply wont run. I'll talk you through what happens when I try to run with WKWebView:

    • The game's start menu loads normally.

    • I choose the new game option.

    • The game successfully goes to my loading layout which I use to show the words 'one second...' before moving to the next layout.

    • The next layout loads but the game only shows the black loading layout with the words 'one second..' frozen on the screen. I can tell the next layout is working fine because all the sound and music is working, and it even accepts touch so the game can be played but the visuals are frozen.

    • Simple non cpu/gpu intensive layouts like my world map load normally.

    • Using the first layout for testing, I've tried disabling all events and the visual still freezes simply trying to load the images in the layout.

    • The layout only works when I delete all but about 5 objects.

    • I've tried creating the images needed for the next layout every few milliseconds in the loading layout before moving to the next layout but this still freezes once the layout changes.

    •Out of simple curiosity I've tried exporting with webGL off, this causes each layout to show the complete sprite sheets for every object in the layout, peculiar!

    Not being very technical, my guess would be that something WKWebView does causes a huge spike in cpu or gpu (I know Ashley has previously said there is no gpu difference between UI and WK but are you 100% sure?) and this causes the visuals to freeze.

    Is there not a more efficient way to load each layout in c2? Most games have a loading screen between each scene, whereas c2 seems to just create everything at the same time regardless of whether this makes the game hang, I'm sure we've all seen crazy cpu jumps for a second at the start of each layout, surely this isn't a healthy way of working?

    In regards to your post , I've found that when I add a new build on TestFlight and try to play it, the loading bar usually hangs half way and I have to close and restart it before it works. This obviously isn't great as if the same problem occurs for users they might just conclude that the game doesn't work and get a refund.

    I can't stress how important I think it is for the c2 team to talk to developers more, especially going forward with construct 3. The test games Scirra uses for benchmarks like Space Blaster are far too simple, you guys need to work with devs to test their actual games, or at least use examples that use large images, sound, and actual layout transitions rather that just one, then we might have known about things like the object limitations of Mac and Linux when using nw.js beforehand. It's all well and good making a great piece of game dev software, which c2 most definitely is, but once it gets to the exporting stage it becomes an absolute nightmare. I can't even count the days I've wasted, hoops I've had to jump through, insane things I've had to figure on my own, and technical posts I've had to decipher in the depths of obscure html5 forums over the last 3 years. These aren't things you should have to do when you've chosen to use a piece of software specifically because you can't code, like I have. Take this small example; every time I export a project for cordova, I have to edit the config and add this below the icon lines or I'll run into an error when uploading with XCode Application Loader for iOS games:

    <icon src="icon-120.png" gap:platform="ios" width="120" height="120" />

    <icon src="icon-152.png" gap:platform="ios" width="152" height="152" />

    <icon src="icon-76.png" gap:platform="ios" width="76" height="76" />

    <icon src="icon.png" gap:platform="ios" width="57" height="57" />

    I literally have done this so much it's second nature, it's ridiculous, why isn't this just a part of the generated config file already? Something like this could permanently stop a user less technically competent than myself, and I'm no coder.

    That really is a tiny example, it's a shame as the people who are really using the software to its fullest potential are the ones getting burned the worst, from Aurel having to discontinue Linux support for The Next Penelope to having their games break with every iOS update! Sorry to rant, I do respect the work Scirra does enormously but I'm just fed up of always looking for answers and seeing every thread end with either; file a bug report, or the dismissive line; we've tested it on this tiny one layout test game and it works fine therefore it should work fine for your game. Users being able to export to the most popular platforms with ease should be a top priority for Scirra, up to this point in time, devs have had to take it upon themselves to create or find plugins and workarounds to do the most simplest of tasks; releasing their game.

    Anyway, if anyone has any ideas please do let me know.

  • The test games Scirra uses for benchmarks like Space Blaster are far too simple, you guys need to work with devs to test their actual games, or at least use examples that use large images, sound, and actual layout transitions rather that just one, then we might have known about things like the object limitations of Mac and Linux when using nw.js beforehand.

    Damn straight this.

    Big C2 games will NOT work on MAC at all, period. Linux export is broken since forever, but honestly I haven't tried it since NW 0.14 so I don't know if it's finally fixed.

    However, it's quite clear this is all related to 3rd party wrappers. NWjs is just broken on MAC with a big project due to being treated like a browser (which isn't supposed to "load so many files", and it's a known bug for years!!). The mobile exporters are worse in their reliance on 3rd parties.

    I would pay a LOT for an engine with C2's event system and native export. We don't need so many damn platforms, just PC/MAC/Linux for the desktop and Android + iOS.

    Back to testing..


    this.isWKWebView = false;

    Now results in a blackscreen, not even a loading bar.

    So definitely that ain't the fix!

    Again, this isn't a WKWebView detection problem, this is related to asset loading somehow..

    If Ashley wants a bigger game CAPX for debug/compatibility/performance testing, I can volunteer mine. The title screen itself has a huge battle, multiple different faction fleets, including capitals and carriers for a lot of sprite, particles, and AI/logic. Let me know!

  • I would pay a LOT for an engine with C2's event system and native export.

    Totally agree with this, the brilliant event system is only let down by the exporting, would be near perfect otherwise.

    I unfortunately had the same results after setting this.isWKWebView = false;

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • As of the latest beta, UIWebView should be working again. So if you have trouble with WKWebView, you should be able to move back to UIWebView and have it work on iOS 10 as of r237. There's also a few more WKWebView fixes in that build. It's unusual for minor iOS releases to make any significant changes, I would initially expect that if it's not working it's not the iOS update that broke it, but who knows.

    The new WKWebView detection code should be working OK, if you change it you'll probably just break things now. In general if you change the runtime script directly without properly understanding what you're doing, you're probably just going to break things and waste time and increase your own frustration.

    Honestly I'm not sure what you want me to say, I'm not telepathic and I can't magically fix the problem because you complained in the forum. WKWebView can sometimes use more memory, so maybe your app is running out of memory. I kind of just have to assume that's what's happening. If you don't provide your .capx or submit a bug report what do you expect me to do? I do test with a few large projects that I've been sent in the past, including source files for Airscape and The Next Penelope, which work fine everywhere I've run them (which is not everywhere, we support loads of platforms and configurations, but the point is I do and can test with large projects). The main problem with these demos though is they're designed for PC, both in specs and user input, so I'm always happy to have different large projects to test with. I do sometimes test very large projects, and it runs out of memory and crashes, and so I have to say sorry, you need to reduce the memory use.

    If you don't think running out of memory is the problem, you can still try to reproduce it: create a new empty project and just jam it full of your game's images/assets/whatever, and see if it breaks sooner than it ought to considering the device's RAM. If it does, now you have an ideal .capx to submit for a bug report. IIRC nobody has done that, for NW.js, for Cordova/WKWebView, etc. Considering it has been very common in the past for people to make games that waste memory and crash the app and then blame Construct 2, I sort of just assume it's that unless you can prove otherwise.

  • Memory waste isn't an issue if the game works flawless in iOS 9 and sudden fails to load in iOS 10+.. I've sent you the CAPX, I have a feeling there's an error with some of the WKWebView workaround no longer functional in iOS10. Hopefully you nail the bug.

  • - thanks for sending the .capx. It looks like WKWebView mode can spike memory usage while loading. The next build has a mitigation which should help a lot with that.

  • Thanks Ashley!

    I've just tested the new build and the WKWebView in XDK/Cordova now loads up fine and runs great.

  • Great, thanks for confirming.

  • Looking for clarification:

    It's been mentioned in several places that WKWebView works on iOS9+, but Apple (https://developer.apple.com/reference/webkit/wkwebview) and several Scirra posts (https://www.scirra.com/blog/150/html5-game-performance-on-ios-8), https://www.scirra.com/blog/174/boosting-ios-performance-with-wkwebview), report that WKWebView was added in iOS8. It would be nice to have this cleared up, as the implication is that exporting in Cordova, with the WKWebView option on, only works for iOS9+, even though the minimum iOS setting still defaults to 8.0+.

    Since I don't have an iOS8 device to test against, it would be nice to know if the new setting will break iOS8 or not.

  • blackhornet

    Technically Apple added WKWebView in iOS8, but it was a partial & broken implementation as it would not allow loading from local files and it did not allow LocalStorage to work properly. There were also major audio bugs.

    In iOS9, these issues were resolved thus the Cordova WKWebView plugin only supports iOS9+!

  • C2 should not allow an export of WKWebView & iOS8 then.

  • C2 should not allow an export of WKWebView & iOS8 then.

    That's still a valid configuration, since it will fall back to UIWebView on iOS 8 and use WKWebView on iOS 9+.

  • Great to see this has been fixed, sorry to moan but it did seem to help get the job done! The reason I didn't send a capx is because I was 99% sure the problem was with WKWebView mode and not my game, though next time I will send one. I haven't had a chance to test WKWebView yet but at least my UIWebView builds are working with iOS 10 now which is great!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)