Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Interesting that initially developers are unable to use much of the hardware. No access to sensors or digital crown.

As usual Apple is starting very conservative. Keep in mind Apple is going from 0-50,000,000 (up to) with no usage history information to build on. Also the HR sensor is involved with security/Apple Pay and will probably be off limits (except maybe exclusive 3ed party developers like Nike) for a while.
 
As usual Apple is starting very conservative. Keep in mind Apple is going from 0-50,000,000 (up to) with no usage history information to build on. Also the HR sensor is involved with security/Apple Pay and will probably be off limits (except maybe exclusive 3ed party developers like Nike) for a while.

What about the digital crown? Unless Apple is still tweaking it and its not really ready for prime time?
 
What about the digital crown? Unless Apple is still tweaking it and its not really ready for prime time?

Just a guess but Apple may want to 'study' the way people interact with the Crown using it's Apps before publishing guidelines on how the Crown should be used. This way Apple could standardize the operation instead of allowing Apps to interact in ways now that may be counterintuitive to the ways Apple determines the Crown should be used.
 
Wrong. Controllers update views, so they have to be aware of the new Watch views added to iPhone application. That code needs to be added, it won't magically work by itself. Also, since you have zero experience in iOS development, you think it's "only a question of designing another set of views" (like dragging and dropping some controls from pallete onto a view, piece of cake!) - you've zero idea of amount of UI glue code behind view controllers that needs to be written by hand.

WRONG!

Controllers link the Views to the Model. The Views query the Models for data.

That's how it should be done. I know only the best programmers do, and for platforms like Java (using Swing), it's not possible.

But on OS X it is, and that's what the books say.

And yes, it's like that, just designing another set of views, assigning the same view controllers, delegates, etc.

If you need to do "glue code", then you're doing it WRONG.
 
Apple missed the train. :apple:Watch is vaporware (Spring 2015? you gotta be kidding) and so is developer support (Summer 2015 to start write first apps? ridiculous)

I'm writing this holding Gear S I got today. It's amazing, and there are already 3rd party apps for it. While Ive is busy talking about his vaporware that's still half a year from being released, other companies are delivering amazing products.

If you really think Apple Watch is vaporware, you're being disingenuous in light of your new Gear purchase.. or you're delusional.
 
If you really think Apple Watch is vaporware, you're being disingenuous in light of your new Gear purchase.. or you're delusional.

How can a product that has an SDK be vaporware?
 
WRONG!

Controllers link the Views to the Model. The Views query the Models for data.

That's how it should be done. I know only the best programmers do, and for platforms like Java (using Swing), it's not possible.

But on OS X it is, and that's what the books say.

And yes, it's like that, just designing another set of views, assigning the same view controllers, delegates, etc.

If you need to do "glue code", then you're doing it WRONG.

Unfortunately, this is just not in this case.

Not all properties can be set view Storyboard so there is not many cases can you just plop in a view that maintains cleanliness and fits an existing view controller, even between iPhone and iPad variations, it's near impossible for such all encompassing code. If you want specialized view animations, structures, controls per device, you'll need a new controller to pair with your view - it's more effort to try and create a "universal" controller than two distinct and specialized classes.

The same goes for WatchOS and iOS. WatchOS does not support 90% of UIKit's view properties or methods, nor do the interactions work the same as iOS. Therefore, you'd need a new controller or a waste of effort retrofitting/complicating preexisting controllers. Controllers do act as glue to the view to the model, and are specialized for each view they maintain. You said it yourself, "The Views query the Models for data," they also query the controller for their state. Their states are different per device, and often different enough that it's within modular design to break up these controllers by the different views they handle.

Programmer of 12+ years, iOS programmer since '09 - You can take my word.
 
Last edited:
Unfortunately, this is just not in this case.

Not all properties can be set view Storyboard so there is not many cases can you just plop in a view that maintains cleanliness and fits an existing view controller, even between iPhone and iPad variations, it's near impossible for such all encompassing code. If you want specialized view animations, structures, controls per device, you'll need a new controller to pair with your view - it's more effort to try and create a "universal" controller than two distinct and specialized classes.

Yes, but those proprieties are dependent of each "version" of the App, and there's no alternative.

For your custom controls, since Xcode 6, you can set up in IB, by annotating @IBDesignable in class, and @IBInspectable in proprieties.

Now if you want specialized something, you obviously need specialized anything.

For the last sentence, it's a matter of opinion, but I disagree.


Controllers do act as glue to the view to the model

Then you may be doing it wrong.




For the rest...

Do you have to recode your App? No!

Do you have a lot of work? No!

There's any possible way to do it easier, cheaper or faster? No!

I rest my case.
 
How can a product that has an SDK be vaporware?

From Wikipedia:

"A developer can strategically announce a product that is in the early stages of development, or before development begins, to gain competitive advantage over other developers.[24] In addition to the "vaporware" label, this is also called "ambush marketing", and "fear, uncertainty and doubt" (FUD) by the press.[22] If the announcing developer is a large company, this may be done to influence smaller companies to stop development of similar products. The smaller company might decide their product will not be able to compete, and that it is not worth the development costs.[24] It can also be done in response to a competitor's already released product. The goal is to make potential customers believe a second, better product will be released soon. The customer might reconsider buying from the competitor, and wait.[25] In 1994, as customer anticipation increased for Microsoft's new version of Windows (codenamed "Chicago"), Apple announced a set of upgrades to its own System 7 operating system that were not due to be released until two years later. The Wall Street Journal wrote that Apple did this to "blunt Chicago's momentum"."

And as we can see, iBrainwashing "just works". :D
 
This developer made a 3D version of Watch and has been using it while doing SDK work.

http://davidhoang.com/2014/11/29/designing-for-apple-watch-before-it-even-ships/

Now, this is the most ridiculous thing I've seen in a long time. To get a feel of what it's like to use a smartwatch, he could have....... just bought a smartwatch! Doh! It's not like :apple: is introducing a new product category, like iPhone and iPad. But it's funny that iSheep behave exactly as if this was the case.
 
Yes, but those proprieties are dependent of each "version" of the App, and there's no alternative.

For your custom controls, since Xcode 6, you can set up in IB, by annotating @IBDesignable in class, and @IBInspectable in proprieties.


Then you may be doing it wrong.

Agree to disagree :)

On another note - it took until Xcode 6 to get @IBDesignable and @IBInspectable - I can't say that they're perfect but finally a start in that territory.
 
To a degree yes, but more importantly, it boils down to how the consumer reacts. If the pricing that is rumored turns out to be true, I don't know how successful it is.

I can see as a developer getting on the ground floor of this and why they were excited. The early developers of the iPhone made a lot of money very quickly. You don't want to let this opportunity slip by.

The pricing isn't rumored. It is confirmed. They start at $349.
If you meant that you don't think it will be popular because there will be a more expensive OPTION... well, that simply makes no sense at all.
 
From Wikipedia:

"A developer can strategically announce a product that is in the early stages of development, or before development begins, to gain competitive advantage over other developers.[24] In addition to the "vaporware" label, this is also called "ambush marketing", and "fear, uncertainty and doubt" (FUD) by the press.[22] If the announcing developer is a large company, this may be done to influence smaller companies to stop development of similar products. The smaller company might decide their product will not be able to compete, and that it is not worth the development costs.[24] It can also be done in response to a competitor's already released product. The goal is to make potential customers believe a second, better product will be released soon. The customer might reconsider buying from the competitor, and wait.[25] In 1994, as customer anticipation increased for Microsoft's new version of Windows (codenamed "Chicago"), Apple announced a set of upgrades to its own System 7 operating system that were not due to be released until two years later. The Wall Street Journal wrote that Apple did this to "blunt Chicago's momentum"."

And as we can see, iBrainwashing "just works". :D

Your daily dose of apple hating.

Maybe you'll win and apple will go bankrupt.

What are you doing in an apple-centric site? Don't you have a life? Or installing a new ROM on your android?
 
Does Nike (and others) get a special SDK?

We know Nike has announced an App and Nike and Apple do have a special relationship. For the Nike App to work it would need access to the HR sensor, accelerometer and the iPhone's GPS.

So will Nike get a SDK for all this?
 
Does Nike (and others) get a special SDK?

We know Nike has announced an App and Nike and Apple do have a special relationship. For the Nike App to work it would need access to the HR sensor, accelerometer and the iPhone's GPS.

So will Nike get a SDK for all this?

I'll bet any money certain hand picked developers will have native apps available for launch. I'm not sure how many but Facebook, Twitter and Nike seem like prime candidates.
 
Does Nike (and others) get a special SDK?

We know Nike has announced an App and Nike and Apple do have a special relationship. For the Nike App to work it would need access to the HR sensor, accelerometer and the iPhone's GPS.

So will Nike get a SDK for all this?

Who said Nike or anyone has a real app, or did they just made some mockups?
 
Who said Nike or anyone has a real app, or did they just made some mockups?

Apple

ScreenShot2014-12-04at53224PM_zpsd04b394e.jpg
 
And it's that a real working app or just a mock up designers threw on adobe photoshop/illustrator?

You would have to ask Apple since it was shown and anounced by Apple at the iPhone/aWatch event. No matter what Apple showed the app would be a near 100% certainty to be released.
 
You would have to ask Apple since it was shown and anounced by Apple at the iPhone/aWatch event. No matter what Apple showed the app would be a near 100% certainty to be released.

And you have to ask Apple/Nike if they got the SDK in advance.

The SDK is almost not needed, because the AWatch runs the same code as what's written for iOS, just with a different UI you can emulate in photoshop.
 
And you have to ask Apple/Nike if they got the SDK in advance.

The SDK is almost not needed, because the AWatch runs the same code as what's written for iOS, just with a different UI you can emulate in photoshop.

I have no idea what you are suggesting, implying or asking.
 
And you have to ask Apple/Nike if they got the SDK in advance.

The SDK is almost not needed, because the AWatch runs the same code as what's written for iOS, just with a different UI you can emulate in photoshop.

I'm going to cut you off and tell you no, again and for real this time, because that is not the case at all. You have to write entirely from scratch to support your new UI for  Watch, unlike I was convinced before.

After digging into the SDK and playing with it for awhile, you can clearly see that you need to rewrite everything (V/C of MVC) in the Watch SDK. WatchKit is NOT the same as UIKit and certainly not a drop-in replacement. Similar, sure, but it's entirely different and not compatible with any UI code you had before (which makes sense). I'm not sure if the full  Watch SDK will be more like UIKit from iOS, but from what I've seen and from what they released, I believe that is just not going to be the case.
 
Last edited:
I'm going to cut you off and tell you no, again and for real this time, because that is not the case at all. You have to write entirely from scratch to support your new UI for  Watch, unlike I was convinced before...

Back to my original question before it was derailed.:eek:

Probably not a question you can answer but speculate and has there been any speculation on the Developer forums?

How will the Nike+ App work on the aWatch? Is Nike (or any other companies) using a 'special' SDK and allowed higher privileges like sensors access?

For instance the Tweeter app will allow you to post from the aWatch.

If not a 'special' SDK then I'm guessing the Nike aWatch App will just be more of a notification App for the iPhone App. Of course to track a run/bike ride you would need the iPhone's GPS anyway.
 

This can't be used for proof. Remember the Photos Extension demoed for iOS 8 (WWDC) that you can turn your photo to water-color painting? No such extension even today.
Sometimes Apple just plainly use concept app.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.