iOS 10 compatibility

Thanks for the super quick response!
Is compatibility expected to come before or after iOS 10 launch?

After the iOS 10 GM release, so probably just before launch.

1 Like

If it helps, here a workaround to test iOS 10 with Xcode 7 : http://stackoverflow.com/questions/30736932/xcode-error-could-not-find-developer-disk-image/37940175#37940175

@martijnwalraven do you know if there is an update on this? iOS 10 due out in about 5 days :slight_smile:

iOS 10 GM just came out, so I plan to take a stab at it soon.

4 Likes

With help from @aldeed, there is now a swift3 branch of cordova-plugin-meteor-webapp that is compatible with Xcode 8. All plugin tests seem to pass on iOS 8, 9 and 10. A newly created app under Meteor 1.4.1.1 also seems to work correctly.

If you want to give it a try with your own app, you can add the latest version of the plugin using:

meteor add cordova:cordova-plugin-meteor-webapp@https://github.com/meteor/cordova-plugin-meteor-webapp.git#8bf95eed3f313299fc2de33658866278eea2cdc5

Xcode may ask you to convert to the latest Swift syntax when you open the project. You should select ‘Swift 3’ as the language version, and analysis should show that no code changes are necessary.

13 Likes

@martijnwalraven thanks very much, that is awesome. do we need to remove or tweak any existing settings, or just install this cordova plugin?

i’ll be testing this out very shortly here.

I can confirm the cordova plugin works great! Few updates maybe needed though:

General > Identity

  • Display Name not automatically set from mobile-config.js App.info.name

General > Signing

  • Automatically manage signing is now checked by default

Build Settings > Signing

  • Needs update for automatic signing, so:
  • Debug & Release should now both be set to iOS Developer

Simple updates. All automatic code conversions to Swift 3, and the other two ‘Recommended Updates’ went through fine and worked great.

Thanks for the awesome work!!

1 Like

Just tested it myself and everything seems to be running great. Thanks @martijnwalraven!

2 Likes

Note that you need to add a content security policy in your html meta in iOS 10, otherwise your app will hang and never connect. Something like this:

  <meta
    http-equiv="Content-Security-Policy"
    content="default-src 'self' 'unsafe-inline' 'unsafe-eval' https://yourdomain.com wss://yourdomain.com https://enginex.kadira.io"
  >

Hope that saves someone a few hours :wink:

3 Likes

Isn’t self and default-src enough?

Seems to be working here too but now I get the error
Download failure: Version mismatch for index page, expected:
What could that be related to?

There is inline js and general inline things you want, so default-src 'self' 'unsafe-inline' wss://yourdomain.com is most likely enough. URLs added are only added for the same origin (scheme, host and port). Since websockets runs over the wss protocol, it seems that you will always need the wss URL definition.

Just remember to test your Meteor app in Safari browser and check the console for errors. Note that any external request will need to be added in a line to content security policy (note kadira’s URL above).

Then, we should give some change to boilerplate-generator package.

https://github.com/meteor/meteor/blob/devel/packages/boilerplate-generator/boilerplate_web.cordova.html#L7

1 Like

@vyky it appears Safari is very over-zealous with the Content-Security-Policy. I tried you recommendation of:
default-src * data: blob: 'unsafe-inline' 'unsafe-eval';

However, I’m still getting report of:
Refused to connect to wss://mydomain.com/sockjs/321/q5m_xkth/websocket because it appears in neither the connect-src directive nor the default-src directive of the Content Security Policy.

This does take care of the need to explicitly define https directorives for your own domain (and kadira), but the wss protocol still needs to be defined. Here’s the line I’m running with for now:
default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob: wss://*.mydomain.com https://*.kadira.io

I’m guessing the * directive is most likely bad practice, as it doesn’t create any additional security at all (which is probably why Safari doesn’t recognize it).

Will there be a fix for older Meteor versions, too? Due to incompatibilities in other Cordova plugins, I am not able to migrate to 1.4 for now. Still on 1.2.

@martijnwalraven I’m receiving this error when looking at Safari console of a mobile build on my phone:

Refused to connect to http://192.168.1.66:3000/sockjs/info?cb=25xazewbgc because it appears in neither the connect-src directive nor the default-src directive of the Content Security Policy.

I believe this is related to some other errors I’ve been receiving through testing all of this. Because of the above, I’m unable to test my Meteor build from either Simulator or a physical device. Also receiving similar errors on production, even when a CSP is set.

The updated Meteor Cordova plugin should work on Meteor 1.3 and 1.4 (there were no Cordova-related changes in 1.4).

That plugin isn’t used on Meteor 1.2, and the old one wasn’t written in Swift, so language changes should not be an issue. I’m not sure what the status of iOS 10 support for the older Cordova version in 1.2 is however. There may be other issues that prevent apps from working correctly in Xcode 8 and iOS 10.

1 Like

@martijnwalraven: Thanks for your fast reply!

Do you receive this error even with http://192.168.1.66:3000 (and perhaps wss:) added to default-src?