As many of you know, I use my Universal Studios app as a test whenever adding new SDK's or testing new functionality. I just had the update approved today which includes TWO new SDK's... Healthkit and Apple Watch. Both were incorporated fairly painlessly. In fact, I even have them stacked in the app, where the Watchkit grabs information from the Healthkit to display on the watch. I'd love to make an Apple Watch plugin, but when you add the files through Xcode, it actually makes some modifications to your project and entitlements, so not sure it would help anyone in plugin form... but don't let Apple Watch intimidate you... it's SUPER easy. Took me less than a day to add Watch functionality to the app, knowing absolutely nothing about watchkit at first. Healthkit is a little more complex (already made a plugin for Healthkit... it's called "Pedometer"). Plus if I was going to do a plugin for Apple Watch, I'd wait until WatchOS 2.0 comes out, which should be very soon... beta 3 is already out. If anyone wants to see the screenshot in itunes of what I have displaying on the Apple Watch, the link to my app is: https://itunes.apple.com/us/app/universal-orlando-tour-guide/id857178975?ls=1&mt=8 It shows the Apple Watch screenshot right below the regular screenshots.

I agree that watch apps are simple to make. I think the health kit stuff is a neat feature to add. Makes the user feel less guilty about all the food they are enjoying.

Nice work, Ninja! :-)

I have *got* to get me one of those watches... Great Work, Ninja! Cheers! -- Smug

Good work! Mike

Great work, I have done some of the basic work for an app I would like made available for the watch. Would be keen to listen to what you have to say in a webinar. You happy to share your experiences? Kristen

Would love to, just a few too many irons in the fire at the moment.

Yes its true that watch apps are simple to make. I also agree with nathevlad that health kit stuff is a an important feature to add. Along with this thanks for sharing such a valuable post. I like the post.

Sorry for the delay guys, I wanted to jump in an elaborate on the watch stuff a bit, I've just been super busy lately. It's true that the watch kit stuff is very easy to work with and add to your project. The catch is that Apple blocks a lot of things that you can do on your regular device with the watch. More on that in a minute. To add Watch capabilities to your existing BT project (or any project), it's as simple at this: 1) In Xcode, go to File>New>Target and select "Apple Watch". This will give you a screen with options to setup the files. Really the only thing you'll want to choose here is the language (obj c or swift) and make sure both checkboxes are ticked for "glances" and "notifications". You can add these later, but it's much more complicated to do so, and it doesn't hurt anything if you enable glances and notifications now and don't use them. Click OK. This creates a storyboard file for your watch app, notification screen and glance screen, all in one file, and adds .h and .m files for each the watch app, the glance, and the notification. It also creates the entitlements file for your app to use the Apple Watch. 2) In the capabilities tab of your project, switch on Apple Watch capabilities. You are now ready to use the storyboard and .h & .m files for the watch just like you would with any other project. Easy, right? So, now that we have our Apple Watch storyboard and .h & .m files, just code away like normal, right? Not quite. Apple has locked out a lot of code from running on the watch itself. Yes, Apple has Watch-Blocked you. Here's an example... In my Universal Studios app, I have a section that taps into Healthkit to obtain the users steps, stairs, distance walked and calories burned. Ok, since I want the screen of the Apple Watch to display this info, and my code to do this in my app is short (1 page), I'll just paste the code into the watch.m file and it will perform the same as my app. WRONG. Upon doing so, I'm presented with an error stating that Apple does not allow Healthkit code to be ran on the watch. I mean, awesome, since the watch is the only Apple device with build in heart rate sensors and is marketed as a health tracking device... of course they wouldn't allow their own Healthkit code to run on it... that would just make too much sense (insert eye roll here). Apple's own suggested solution? Retrieve the data using your iPhone, then pass it off to the watch screen. Ok, I guess I can work with that. So, I try to... SecondViewController *watch = [[SecondViewController alloc] initWithNibName:@"" bundle:nil]; [watch.view addSubview stepCount]; [wtach.view addSubview calorieCount]; Guess what? Error. Apple doesn't allow watchkit code to retrieve data, text or info from other views of your app! WHAT?!?!? Back to the Apple support docs. It turns out their official way to do this is to store whatever you want to pass along to the watch app in either a dictionary file or NSUserDefaults and retrieve them using the watch's implementation file. I chose to use NSUserDefaults, as I'm more comfortable with their usage. It works, and pulls the data, but stops updating the data after about 20 minutes because it's not accessing Healthkit directly (healthkit keeps track of all this data in the background, without having any apps open). Because of the work around, my NSUserDefaults only saves the updated data when the data labels in my app update, which is only when that view is open and the user is looking at it. Great for my app... not so much after > 20 minutes with the watch screen. In order to have the watch update itself after 20 minutes, the user is going to have to open my app and go to that screen, which kind of defeats the purpose of having everything on your watch so you don't have to take your phone out of your pocket. I haven't tried yet, but the best solution I can come up with is to try to have a code in the watch files that says "if more than 20 minutes has passed since last refresh, open the app on the iphone (probably in the users pocket), and go to the healthkit screen, then refresh the watch screen and restart timer for another 20 minutes". Not sure if that's allowed yet. It would also factor into the users battery life on their device. I think I may do something like above, but instead of automatically firing the refresh, present a small button on the watch screen that says "force refresh" and a little warning underneath it stating that the app will open on their iPhone when this happens. My last pet peeve with Watchkit is laying out the controls on the storyboard. You cannot overlap controls. You can't lay things out exctly where you want. Instead you have to use Apple build templates, where Apple thinks you want stuff laid out. There are 10 included in Xcode, and you cannot alter them, add more, or otherwise design the way you want. You're forced to use the layouts they think are best. It sucks. Easy to implement? Sure. Easy to work with? Ok. Easy to code so that it works and displays like the rest of your app? No way. Apple locks it down so much that it's really hard to get things to display and function in the most efficient manner. Instead, you'll spend all day trying to figure out workarounds for simple functions that would normally take you 30 seconds to implement.

Plugins + WatchKit...Hmm.. Lots of us have been tinkering with WatchKit since it's release and most of us understand the difference between dynamically loading Class files and class files (and other assets) complied prior to Runtime. Instantiating Classes and triggering methods (called selectors in Objective C) must be done dynamically when using a Plugin Architecture like we've all gotten used to. Niraj sent me an interesting blob post the other day raising this exact topic. The post was about Swift's progress in this regard. That's another topic. But, "selectors from strings" are not... Our Xcode projects are aware of all the plugins you've included before you compile. Our compiled projects can launch a plugin, and fire a method in any plugin Dynamically, at runtime. Don't confuse firing a method dynamically with firing a method in uncompiled code. Big difference. We're compiling code included in our projects, then firing methods at runtime. In most cases this is done using the "selector from string" approach. //create a selector from a string-name (we can get this string from anywhere, like the JSON)... SEL nirajMethod = NSSelectorFromString(@"doNirajMethod"); //use this selector... if[NirajPlugin respondsToSelector:nirajMethod]){ //do something cool here... } It's a super flexible idea. If Niraj's class (his plugin) supports the method we can call it without previously understanding this. Cool. However, we can't dynamically do this with WatchKit. We can't say "Hey, if this Class file is launched, probabaly a UIViewController sub-class we call a plugin, magically include a Watch App or some Watch functionality. It makes perfect sense that this is true. BUT, if we know in advance that the app already has a WatchKit component, we could easily do exactly that. Working with WatchKit is super easy. Configuring your project to include a Watch App in the compiled Bundle is also easy (as pointed out above). What's not easy is getting our download server to either either a) include a WatchKit app your app bundles or b) NOT include a WatchKit app in your project bundle. Easy if we know, not so easy if we don't. It's more a issue of how the backend download process works and how your project is prepared after using the control panel to create it. An "include WatchKit" option seems logical but were a ways from having all the necessary parts available to package in your downloads. We'll get there eventually I suppose. Great conversation, and I'm determined to figure out how to do this dynamically :-)