WWDC, iOS 8, Xcode 6, OS X Yosemite: respect your Developer PLA!

[Kerri Shotts]

The WWDC keynote was amazing. A few big surprises, lots of stuff we already assumed. All that said, bear the following in mind (and I don't mean to be a pedant, but I think it is important to say):

• iOS 8, OS X Yosemite, and Xcode are beta softwares. PG cannot offer support for these softwares are they are not yet publicly available. This means that you operate under the betas at your own risk.
• PG will not be compatible with the above softwares until sometime after their public release. It is entirely possible that PG will experience problems with the beta versions prior to release, but those configurations must remain unsupported. (All frameworks are in the same boat here.)
• Respect your developer PLA -- Apple showed a lot of stuff at WWDC, but there's a lot more that should probably be regarded as confidential. [I'm of a mixed mind when it comes to bug reporting for iOS 8 here -- the bugs need to be reported and tracked, but it might also violate your PLA. Perhaps the devs/moderators have an opinion on this matter. ]

Now, get busy downloading all the new cool betas, exercise proper judgement when talking about everything that's new and cool in there (and what's not), and have fun. There's going to be a lot of work and learning involved for many of us in the upcoming few months, I think!

[Tom Wilson]

The swift programming language looks like it's publicly available so we should be able to talk about it.  

Does anyone have any opinions on how this could impact phonegap?  

I've been putting off learning objective c, but swift looks like it'd be pretty easy to pick up.

This guy has already offered an example using swift to create a ViewController and set some properties on it.  And it should work in ios7!

http://stackoverflow.com/questions/24001778/do-swift-based-apps-work-on-os-x-10-9-ios-7-and-lower

How much work would it be to use swift to create a phonegap plugin?

I haven't dived into any of the new api's in the sdk to see if those would benefit UIWebViews and they are probably under NDAs while ios8 is in beta.

Thanks!

Tom

[Shazron]

Swift is binary compatible on iOS 7 or greater and OS X 10.9 or
greater (Platforms State of the Union)

> --
> -- You received this message because you are subscribed to the Google
> Groups "phonegap" group.
> To post to this group, send email to phon...@googlegroups.com
> To unsubscribe from this group, send email to
> phonegap+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/phonegap?hl=en?hl=en
>
> For more info on PhoneGap or to download the code go to www.phonegap.com
> ---
> You received this message because you are subscribed to the Google Groups
> "phonegap" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to phonegap+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Kerri Shotts]

Tom,

To the limits that Swift is described, yes, it should be free to talk about. Of course, Swift is just the language -- it has nothing to do with the additions or changes made to the SDK, most of which are still under NDA, of course.

As to how Swift will impact PhoneGap -- here's my thoughts:

 - Initially: very little impact at all. Swift interops with Obj C just fine, so there's no need to rewrite what works. The only reason to do so would be to improve performance (Swift can be faster) or of Obj C goes away. I doubt there's much performance increase that can be pulled out of PG's startup simply by switching languages (most of this deals with instantiating a web view, which takes time, and then code running within that web view), and Obj C isn't going away any time soon.

- Short-term: I expect PhoneGap will begin seeing Swift-powered plugins. I haven't tried writing one yet, but it might lower the entry barrier when it comes to writing native plugins. OTH, it does nothing for the SDKs, which is the majority of what one has to learn. Syntax is easy -- SDKs are hard.

- Long-term: I expect that if Swift takes off like Apple hopes, Obj C will eventually be deprecated. I expect that over the years, Swift will be able to do everything Obj C does now (and it looks like it can do that /now/, from my cursory glance), and the language will be continually improved. If the developer community switches to Swift en masse, there will be little incentive to continue Obj C enhancements, IMO. Prior to that point, I would expect that PG would slowly migrate bits and pieces over to Swift as the developer community also migrates from Obj C to Swift. (Even if only through attrition.) I would expect this process to take years within the community, so whether or not PG would switch as quickly remains to be seen. I guess it depends on the influx of new committers who work in the language.

Swift itself looks like an interesting language, with a lot to love, and with a few failings from my cursory overview:

 - Parts of it feel like an ObjC wrapper, only prettier -- akin to CoffeeScript over JavaScript. There are a few places where Apple should have made a more obvious break from the Obj C underpinnings -- but of course, with Obj C interop a de facto requirement, this would have been difficult to accomplish.

- Parts of it feel like a language designed by committee. I'm not terribly in favor of operator functions, for example -- a + should not be able to be overridden -- at some point some one is going to have the operator do something funny, and the code is no longer self-descriptive. That c-style for-loop is dreadfully out-of-place when considering the other loops, imo.

- Parts of it feel like doing a thing simply to do that thing. For example, a common error with zero-based arrays is to loop from 0 through to the length -- which will result in a range error. Swift's solution to this is to introduce two range operators: the "..." operator which operates on all the values inclusive (0...3 = 0,1,2,3), and the ".." operator which operators on all the values but the last (0..3=0,1,2). Now, I don't know about you, but that is not at all immediately apparent from my reading of the source code. Sure, it might eliminate one class of mistakes, only to replace them with another class entirely (or a couple). Much better, in my opinion, to have done something like this: [0...3]=0,1,2,3, [0...3)=0,1,2, (0...3)=1,2, (0...3]=1,2,3. Consistent, and makes sense when reading the source (although it only does so with integers, since reals would imply 0.00...01 - 2.99..99). But honestly, why can't we write "for x in 0..(length-1)": it makes sense, and what is going on is clearly visible in the source without having to know the esoterica of the language. The ? and ! operators feel a bit like this too, in my opinion, and add a level of obtuseness to the language that it doesn't need. I understand the point is to reduce having to worry about nillable variables, but to someone who doesn't know the language ? and ! are going to come across as "odd" -- in much the same way as "[...]" came across in Objective C.

- Did I miss it, or is there really no try...catch/exception handling here? I did a search to be sure, and I don't see it anywhere. I suppose multiple return values from functions helps (so being able to return a value and a failure/success message). I know Apple eschews exception handling for various reasons, but I was surprised to not see this make an appearance for user code at the least (even if the SDK didn't use it).

- No async handling built in -- I assume Apple is relying on their other thread handling methods in the runtime to handle this, but it would have been nice to have direct equivalents to yield and such.

- A few of the keywords just feel funny: why `func` vs `function`? Why `init/deinit` vs `func init` and `func destroy`? (I know there are reasons, but it still feels funny to me...)

- ARC is very much a mainstay of the language. As much as I like ARC, I wonder if it should be so tied into the language. Furthermore, it seems to me that if Apple is going to do some magic under the hood (as they are doing with object copies, but only when needed, etc.), why not go a little further with that magic and eliminate the need for [unowned self]? The need for the declaration is important, but I would think the use case here is reversed -- when I want to capture self strongly, perhaps I should declare it then, and the compiler should assume a weak capture by default. Otherwise this particular class of mistake isn't going to be eliminated (unless there are warnings thrown to the user saying "are you sure you mean to capture self strongly?"). 

- A definite ObjC-ism is the way named parameters are handled. There's very clearly a thin veneer going on here -- and I'm not sure I like it. Especially in the declaration -- what in the world is that "#" doing there? Personally, I think this would be a common use case so that it should go the other way, but there really should be some other syntactical method of declaring what is an externally named parameter vs an internally named parameter. (Or better: do away with the distinction entirely.)

- I really don't like let vs var. I'd much prefer const vs var here. The semantics are much more clear. 

Now all that sounds like I'm really down on the language -- I'm not, really! There's a lot in there to like and love, and I can't wait to actually dig in to it. Having the playground is even better and should help speed up dev time and encourage "try this out to see what it does". And there are nutty things Obj C does too, so Obj C doesn't get off the hook here either.

Of course there are aspects of it that could change -- Apple isn't promising source code compatibility until iOS 8's release (I think that one is safe to say), so don't be surprised if something breaks in the upcoming months. 

As to working in iOS 7, from what I've seen elsewhere, the WWDC app itself is written in Swift. So Apple is clearly dogfooding their own product. I wonder how much else has been written in it that we don't know about. Given that this has had to take years to build (and the docs admit that), I expect much more of Apple's products are written in Swift (or have portions written in Swift) than we know.

[Tom Wilson]

What's cordova/phonegap's policy on deprecating ios versions?  I'm already only supporting ios7+ since I want to skip testing ios6.  Ios6 is at 10% usage rate.  Does this have to dip a little further in order to start thinking about deprecating it on phonegap?  

[Kerri Shotts]

It's worth pointing out that that 10% can be a little misleading when you consider specific markets. It wouldn't surprise me to learn that in certain markets iOS 5 and 6 take up a large enough portion of the install base that it's still worthwhile to support. If you looked at my family, for instance, you'd see that iOS 7 has two devices (iPad 3, iPhone 5s), iOS 6 has one (iPhone 4), and iOS 5 has two (iPad 1s). That said, as a dev, I don't support iOS 5 anymore at all -- too much lost to maintain support -- but I do try and support iOS 6 whenever I can (although in doing so, I tend to force the iOS 7 L&F onto iOS 6 as much as is possible).

[Shazron]

It's slow. We only recently dropped iOS 5, and only support iOS 6 and
7. In general, we support the current and previous version of iOS. The
decision is by consensus.

Two factors:
1. Testing
2. Actual usage numbers

If we don't have any devices to test with iOS version X, we can't
vouch for it, so unfortunately we will have to drop it. And we do need
those old devices with the older iOS version, because -- even with
Deployment Target = version X, if you happen to use a version X+1 API
call on a version X device, it will crash.

[Shazron]

We can talk about pre-release stuff, with certain conditions - imo:
http://oleb.net/blog/2014/06/apple-lifted-beta-nda/

[Tom Wilson]

Has anyone checked out the ios8 api diff section.  

There is a WebKit class now with a bunch of new options.  Any ideas if this would support the Nitro rendering engine that's used in ios Safari?  It looks like phonegap could take advantage of some of these additions.

https://developer.apple.com/library/prerelease/ios/releasenotes/General/iOS80APIDiffs/index.html

Search for "WebKit" at the bottom

You received this message because you are subscribed to a topic in the Google Groups "phonegap" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/phonegap/LtcxHCOMrYc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to phonegap+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Tom Wilson

Alpine Metrics Lead UI Developer

tom.w...@alpinemetrics.com

920.445.8898

203 Enterprise Blvd, STE 3
Bozeman, MT 59718

http://alpinemetrics.com

[Kerri Shotts]

!!!!!!!!!!!!!!!!

About time for Apple to let us talk about this stuff. Finally!

So can't wait to dig into it all. :-)

[Kerri Shotts]

Looks really interesting, doesn't it? Time to get playing...! :-)

[Tom Wilson]

From this post, it does look like the new webkti api's uses the Nitro javascript engine which is great news for phonegap.

http://appadvice.com/appnn/2014/06/under-ios-8-all-third-party-web-browsers-can-be-as-fast-as-safari

[jcesarmobile]

We can watch some WWDC videos

https://developer.apple.com/videos/wwdc/2014/

I'm going to see "Introducing the Modern WebKit API" right now!

[Tom Wilson]

Watching the webkit video now.  Looks promising. UserScripts and ScriptMessages look sweet.

Can you use the WKWebKit API on an ios7 phone?  If your app is built with the ios8 sdk, would that enable it to be run on a device with ios7, or do you need to wait until the device is on ios8 to use the WKWebKit api?

[Kerri Shotts]

I'm imagining a new native <-> www bridge. :-) 

Plus Nitro / LLVM should put our apps back on par with Safari's speed. Nitro is great, but I'm super-psyched for the LLVM stuff going on. 

AFAIK, though, this only works on iOS 8+ -- they did say that this was what we should switch to if we're writing new apps. I'm not sure if this has any impact on existing UIWebViews (it would be awesome if they at least got Nitro support by default -- then we could support iOS 7/8 without too many worries on the native side without duplicating code...) 

[Shazron]

https://issues.apache.org/jira/browse/CB-6863

[jcesarmobile]

After watching the video, it seems apple now is going to change their policy from banning apps that just wraps web pages, to allow apps that just wraps web pages but enhance the experience.

Worst thing is, it seems there is no way to communicate from objective-c to the web whenever you want after it has been loaded, the only options are injecting the script before loading or when it finish loading

[Kerri Shotts]

Yeah, this is a problem -- I didn't catch it during the first watch, though. Time to file some radars, I guess. 

[jcesarmobile]

It seems they have added a method for executing javascript on the WKWebView
http://trac.webkit.org/changeset/169765

[Kerri Shotts]

Niiiice.

Hopefully this shows up in Beta 2. The sooner the better.

[Shazron]

Awesome! Thanks jcesarmobile - adding this info to
https://issues.apache.org/jira/browse/CB-6884

On Sat, Jun 14, 2014 at 1:32 AM, jcesarmobile <jcesar...@gmail.com> wrote:
> It seems they have added a method for executing javascript on the WKWebView
> http://trac.webkit.org/changeset/169765
>

[MattDavid]

The new WebKit view is really cool as it will use Nitro on iOS to powerboost the JS. We also get WebGL!! Will the older WebKit be supported with the new WKWebKit?

[Kerri Shotts]

Not sure what you're asking? The old UIWebView class is still present, but Apple is saying it would be wise to move to the new class as soon as possible (depending on what you support).

[Tim Stewart]

Has anyone actually tried making a PG plugin using Swift? I tried but it didn't work, but I am not a PG plugin expert, so I decided to load an existing PG plugin (console) to see where I may be going wrong. Found that although console plugin works as expected when run from xcode 5, the native call never happens when run in xcode 6. Anyone know of a setting etc. that may need to be changed to get this to work? Or will it need a more fundamental change on the PG side?

I realize, as stated earlier in the thread, that there is no reason whatsoever that PG should work on and support a beta platform. I was just hoping someone else might be playing with Swift for a PG plugin (or even just trying to get a project with an ObjC plugin to work in xcode 6) and might have a suggestion. 

Cheers

Tim

[Kerri Shotts]

I've been exceedingly curious to try making a PG plugin with Swift, but I haven't had the time to do it yet. :-/

[Tim Stewart]

I found why the console plugin (or any other PG plugin) was not working: https://issues.apache.org/jira/browse/CB-6863.

Thanks

Tim

[Tim Stewart]

Got the Swift plugin working. One gotcha to look out for is you need to specify the Swift class name with an @objc annotation, otherwise the class cannot be instantiated and CDVViewController.getCommandInstance returns nil.

Thanks

Tim

[Anuj Sharma]

Hello Sir, I am working in Xcode 6 Beta and using cordova 3.5.0. But plugins are not working in this. So as per this dicsussion is this the reason that Beta version not supported by Phonegap ?
and suggest me which Xcode version i should use to develop IOS application.

[jcesarmobile]

Use Xcode 5.1.1

[Justin]

Please forgive my ignorance, but what is a PLA?

[jcesarmobile]

Private License Agreement

But I usually see it as NDA instead (Non Disclosure Agreement)