I'm not saying that there won't be some OS changes when the new phones are rolled out -- but I'd expect them to be minor or limited to Apple-only apps.
At WWDC 2014, Apple significantly opened up new and previously closed APIs to developers. There are lots of things for developers to exploit and much to keep them busy.
If Apple were to announce new iOS features/APIs at rollout of the new iPhones -- most developers would not have time to take advantage of them.
There are exceptions, of course -- like the 2 game developers who got early info on Metal, and demo'd apps at WWDC.
One good candidate for rollout iOS change would be to HomeKit -- to allow an AppleTV or Mac to be the local controller -- instead of relying on the iPhone. But this could be easily handled under the covers -- or by opening the kimono to a few HomeKit developers under NDA.
IMO, the biggest WWDC announcement was Swift ... then the later IBM partnership using Swift. I think there will be exponential growth in SMB and Enterprise apps -- from Apple/IBM, Existing enterprise app developers, IT, large developers and Indies.
With Storyboards and Swift, we are getting to the point that developing apps for mobile or the desktop is as easy, if not easier, than developing web apps.
var AAPLsharePrice = 100
let yea = "????"
(AAPLsharePrice >= 100 ? println("\(yea) Laissez les bon temps rouler") : println("????"))
Will give:
???? Laissez les bon temps rouler
Swift continues to change so I doubt serious devs are tackling it. Even IBM. Not until the end of beta. It's a myth that it makes programming for the iPhone or Mac much easier given than the real knowledge you need when programming either is the frameworks.
Excellent point, and that's exactly what I'm hoping for.
Not happening.
We won't see a 4 inch flagship phone from Apple ever again.
Can you elaborate on that? Bit difficult to respond with an 'ok, thanks' without you giving any indication as to why. Not asking for proof, obviously, but since it's your opinion I'd like to read why you think this should be taken as truth.
I see gomers with these huge slabs held up against the side of their heads and think the phone should have come with that helmet they shouldn't be allowed out of the house without. Does Apple want all of their customers to look like fucking spazzes? Maybe, but I'm not convinced.
I'm not saying that there won't be some OS changes when the new phones are rolled out -- but I'd expect them to be minor or limited to Apple-only apps.
At WWDC 2014, Apple significantly opened up new and previously closed APIs to developers. There are lots of things for developers to exploit and much to keep them busy.
If Apple were to announce new iOS features/APIs at rollout of the new iPhones -- most developers would not have time to take advantage of them.
There are exceptions, of course -- like the 2 game developers who got early info on Metal, and demo'd apps at WWDC.
One good candidate for rollout iOS change would be to HomeKit -- to allow an AppleTV or Mac to be the local controller -- instead of relying on the iPhone. But this could be easily handled under the covers -- or by opening the kimono to a few HomeKit developers under NDA.
IMO, the biggest WWDC announcement was Swift ... then the later IBM partnership using Swift. I think there will be exponential growth in SMB and Enterprise apps -- from Apple/IBM, Existing enterprise app developers, IT, large developers and Indies.
With Storyboards and Swift, we are getting to the point that developing apps for mobile or the desktop is as easy, if not easier, than developing web apps.
var AAPLsharePrice = 100
let yea = "????"
(AAPLsharePrice >= 100 ? println("\(yea) Laissez les bon temps rouler") : println("????"))
Will give:
???? Laissez les bon temps rouler
Swift continues to change so I doubt serious devs are tackling it. Even IBM. Not until the end of beta. It's a myth that it makes programming for the iPhone or Mac much easier given than the real knowledge you need when programming either is the frameworks.
Yes, Swift continues to change -- it is evolving, but it is reasonably stable for a beta. I'd say it is no worse than other new frameworks as far as bugs, work-arounds or learning difficulty.
As I see it, the advantages of Swift are (in no particular order):
all the code you don't have to write
readability and ease of code maintenance
interactive development, testing and debugging
safe code -- if it compiles it will run
speed of execution
graceful migration - coexistence with Obj-C within an app
Having worked in IBM Development, I think IBM will be all over Swift -- it is a rare opportunity (for both Apple and IBM) to learn from each other, to define/solidify the language, to add features to satisfy the needs of both of their target customers, exploit a competitive advantage and to enhance the appeal of their product and service offerings.to
One final thought -- the ease of coding debugging interactively in Playgrounds then copy/pasting that code into classes for compilation is almost trivial.
For example here's a modification of my earlier example that runs in a Playground.
import UIKit
var str = "Hello, playground"
class ViewController: UIViewController {
@IBOutlet var stockPrice : UILabel! // Add Output field to UIView
override func viewDidLoad() {
super.viewDidLoad()
let url: NSURL = NSURL(string: "http://localhost/aapl"
let aaplPrice: Double = (NSString.stringWithContentsOfURL(url,
encoding:NSASCIIStringEncoding, error:nil)).doubleValue
var label: String = "AAPL Stock price is $\(aaplPrice) "
if aaplPrice >= 100 {label += "????"} else {label += "????"}
println(label)
// stockPrice.text = "\(label) " // Set Output field in UI View
}
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
// Dispose of any resources that can be recreated.
}
}
let myVC = ViewController()
myVC.viewDidLoad()
As you can see, I included the ViewController code in the Playground. All you have to do to execute the code is to create an instance of the VC, then call the viewDidLoad func.
When debugged, you just copy/paste the whole ViewController Class into the class file for compilation.
Note: as implemented, the commented stockPrice.text field causes an error in the Playground because it references an IBOutlet in the UIView. -- it needs to be uncommented for compilation of the ViewController Class.
If you want to see how the UIView actually looks as the Playground is executing, you can write a little extra code to create a UIView and the various fields. I've done this with TableViews, but it's a little too retro for most needs.
However, at some point I expect Apple will integrate Storyboards and Playgrounds -- so you can interactively design and debug your apps.
Can you elaborate on that? Bit difficult to respond with an 'ok, thanks' without you giving any indication as to why. Not asking for proof, obviously, but since it's your opinion I'd like to read why you think this should be taken as truth.
past history with iphones.
once they go bigger they don't go back.
I'd be shocked if they bring an iPhone6 with a 4 inch screen.
Apple is all about product differentiation.
The top line phones will have a larger screen, metal body, and all the new tech (sapphire)
The mid/low phones will have smaller screen, plastic body
When the iPhone5 was released many opted for the 4S because the product was almost the same except for screen size. Apple really wants people to buy the top end phone so they will create a large gap between the two.
Ah, ok. Well, if they release a 4.7" screen iPhone that is has a larger FF than the current model I won't be buying it. It's already large enough, some of my pants 'have a problem with it' meaning the phone 'drops landscape' in my pocket and it 'a bit difficult to take out'. Yes, in diacritical mark, because it obviously ISN'T A BIG problem, but still, not preferring a larger phone than it already is.
Yes, Swift continues to change -- it is evolving, but it is reasonably stable for a beta. I'd say it is no worse than other new frameworks as far as bugs, work-arounds or learning difficulty.
As I see it, the advantages of Swift are (in no particular order):
all the code you don't have to write
readability and ease of code maintenance
interactive development, testing and debugging
safe code -- if it compiles it will run
speed of execution
graceful migration - coexistence with Obj-C within an app
Having worked in IBM Development, I think IBM will be all over Swift -- it is a rare opportunity (for both Apple and IBM) to learn from each other, to define/solidify the language, to add features to satisfy the needs of both of their target customers, exploit a competitive advantage and to enhance the appeal of their product and service offerings.to
One final thought -- the ease of coding debugging interactively in Playgrounds then copy/pasting that code into classes for compilation is almost trivial.
For example here's a modification of my earlier example that runs in a Playground.
import UIKit
var str = "Hello, playground"
class ViewController: UIViewController {
@IBOutlet var stockPrice : UILabel! // Add Output field to UIView
override func viewDidLoad() {
super.viewDidLoad()
let url: NSURL = NSURL(string: "http://localhost/aapl"
let aaplPrice: Double = (NSString.stringWithContentsOfURL(url,
encoding:NSASCIIStringEncoding, error:nil)).doubleValue
var label: String = "AAPL Stock price is $\(aaplPrice) "
if aaplPrice >= 100 {label += "????"} else {label += "????"}
println(label)
// stockPrice.text = "\(label) " // Set Output field in UI View
}
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
// Dispose of any resources that can be recreated.
}
}
let myVC = ViewController()
myVC.viewDidLoad()
As you can see, I included the ViewController code in the Playground. All you have to do to execute the code is to create an instance of the VC, then call the viewDidLoad func.
When debugged, you just copy/paste the whole ViewController Class into the class file for compilation.
Note: as implemented, the commented stockPrice.text field causes an error in the Playground because it references an IBOutlet in the UIView. -- it needs to be uncommented for compilation of the ViewController Class.
If you want to see how the UIView actually looks as the Playground is executing, you can write a little extra code to create a UIView and the various fields. I've done this with TableViews, but it's a little too retro for most needs.
However, at some point I expect Apple will integrate Storyboards and Playgrounds -- so you can interactively design and debug your apps.
Nothing in that code which couldn't be done in objective c of course, albeit without the compile error. Most of the work is the frameworks. At the moment swift is unstable in its design, it's philosophy of design in many ways, the debugger, playgrounds, interaction with objective C, the compiler and debugger. Which is a lot.
Is it easier to understand than objective C? Sometimes. Sometimes not. See generics.
They have in many cases - and this is a design philosophy - sacrificed code readability on the alter of code compactness. Which is the opposite of objective C. We'll see. I have plans to write some swift code in my large mac project targeting Yosemite. . I've tried already but code which worked in the playground failed with a compiler exception in the real build. That's not good.
It does reduce potential crashes caused by nil pointers passed into some framework API. Performance is not really obvious.
September used to seem so far away, but just a few more weeks to go. The 4S has been good to me but I'm more than ready to pull the trigger on a new iPhone. The wait is nearly over.
I am going to give myself a 4 week Appleinsider sabbatical because I want to be awed again.
Last year was a bit miserable with all the 5C leaks. There were no surprises left.
This year I am pleasantly surprised not having seen a finished (part of the) iPhone. We're completely clueless about the design, which is great.
My money is on anunapologetic plastic 3.5" iPhone mini. Mint green would be totally awesome! (One can Dream). I imagine the 5.5" folks going mental if the iPhone mini were to be "the one more thing".
September 9th is a questionable date for such an event considering that the Back To School promotion runs through September 9th - unless Apple intends to announce things but not make them available on launch day, which would disappoint and detract from the presentation.
I see gomers with these huge slabs held up against the side of their heads and think the phone should have come with that helmet they shouldn't be allowed out of the house without. Does Apple want all of their customers to look like fucking spazzes? Maybe, but I'm not convinced.
Ah, you must be one of those people who insist on trying a new phone on in front of a mirror to see how it looks on you. No, nothing superficial and shallow about that. *snicker*
Nothing in that code which couldn't be done in objective c of course, albeit without the compile error. Most of the work is the frameworks. At the moment swift is unstable in its design, it's philosophy of design in many ways, the debugger, playgrounds, interaction with objective C, the compiler and debugger. Which is a lot.
I wasn't trying to show things that couldn't be done in Obbj-C or vise versa. Rather, I was trying to illustrate the workflow going from interactive debugging to a compiled app. I could have eliminated the compiler error, but I thought it better to be honest and note that you, likely, will have slightly different versions of code in the Playgrounds and in the compiled classes (at least for now).
Yes, most of the work is in the frameworks -- and much of the problems is unlearning the Obj-C way and relearning the Swift way ... It's more than different syntax, its a different approach to the way you attack a task.
I will concede that Swift is somewhat unstable in design -- I think that Apple enjoys (and exploits) the luxury of not having a Swift install base (it's only been available for a little over a month) ... They don't need to deprecate things to protect existing developer code -- They just change things and the devs need to go with the flow.
I expect this evolution/instability to continue until the GM (a week before the iPhone availability) when they will accept Swift apps for the App store.
Is it easier to understand than objective C? Sometimes. Sometimes not. See generics.
They have in many cases - and this is a design philosophy - sacrificed code readability on the alter of code compactness. Which is the opposite of objective C. We'll see. I have plans to write some swift code in my large mac project targeting Yosemite. . I've tried already but code which worked in the playground failed with a compiler exception in the real build. That's not good.
It does reduce potential crashes caused by nil pointers passed into some framework API. Performance is not really obvious.
I, too ran into several cases where code that worked in Playground (ha, almost typed Praygrounds) failed to compile. Before I could submit a bug, beta 5 eliminated the problem.
I have been doing some performance comparisons with > 10K packets coming down the line from a web site/service.
I don't think that Apple has rewritten the JSON serialization/deserialization routines to exploit Swift, yet -- so I don't expect any improvements here -- yet!
But I've been testing an alternative to JSON, XML, etc. -- all that verbose crap. I've been timing building arrays and dictionaries using String, Any and AnyObject. Beta 5 Swift is 1 - 2 orders of magnitude faster in some cases.
This performance should really appeal to IT and IBM who need to shlep around big data.
Some bugs between Swift compiled code and Playgrounds have been fixed.
But the greatest thing I noticed is more than an order of magnitude performance improvement to create a large array of AnyObject:
On the prior release, the time to create theArrayAnyObject was ~ 0.021 sec (similar to both other arrays.
.....With this release, the time to create theArrayAnyObject was 0.000947952270507812 sec
This totally aces JSON or XML deserialization ...
Look out big data, here we come !!!
countElements(theSource): 7122
timeBegin: 428870004.437607
timeEnd: 428870004.459515
elapsed time: 0.0219079852104187
Total creationTime: theArrayString 0.0213939547538757 sec for 1787 entries
timeBegin: 428870004.463015
timeEnd: 428870004.464475
elapsed time: 0.00145995616912842
Total creationTime: theArrayAnyObject 0.000947952270507812 sec for 1787 entries
timeBegin: 428870004.46858
timeEnd: 428870004.496807
elapsed time: 0.0282269716262817
Total creationTime: theArrayAny 0.0276419520378113 sec for 1787 entries
Ah, ok. Well, if they release a 4.7" screen iPhone that is has a larger FF than the current model I won't be buying it. It's already large enough, some of my pants 'have a problem with it' meaning the phone 'drops landscape' in my pocket and it 'a bit difficult to take out'. Yes, in diacritical mark, because it obviously ISN'T A BIG problem, but still, not preferring a larger phone than it already is.
I'm sure Apple will continue on with the 4" at least with the plastic version. I wouldn't mind seeing the iPhone go to 16:9, the could fit a 4.5" screen without going any bigger, 4:3 isn't really all that benificial in a phone anyway. I understand the iPad using 4:3 and actually really like the similar aspect ration in the Surface as well but in a phone I don't see much of a difference.
I saw this today on businessweek Quote "Apple (AAPL) has scheduled a press event for Sept. 9, and a source tells Bloomberg News that this will be the occasion for the release of the next generation of iPhones. "
I mean have they now, where are the cryptic invitations?
Ah, ok. Well, if they release a 4.7" screen iPhone that is has a larger FF than the current model I won't be buying it. It's already large enough, some of my pants 'have a problem with it' meaning the phone 'drops landscape' in my pocket and it 'a bit difficult to take out'. Yes, in diacritical mark, because it obviously ISN'T A BIG problem, but still, not preferring a larger phone than it already is.
I'm sure Apple will continue on with the 4" at least with the plastic version. I wouldn't mind seeing the iPhone go to 16:9, the could fit a 4.5" screen without going any bigger, 4:3 isn't really all that benificial in a phone anyway. I understand the iPad using 4:3 and actually really like the similar aspect ration in the Surface as well but in a phone I don't see much of a difference.
The iPhone has never been 4:3. Originally it was 3:2; it went to 16:9 with the iPhone 5. This is a horrendous aspect ratio for anything but a TV—it's much too narrow in portrait.
Ah, ok. Well, if they release a 4.7" screen iPhone that is has a larger FF than the current model I won't be buying it. It's already large enough, some of my pants 'have a problem with it' meaning the phone 'drops landscape' in my pocket and it 'a bit difficult to take out'. Yes, in diacritical mark, because it obviously ISN'T A BIG problem, but still, not preferring a larger phone than it already is.
I'm sure Apple will continue on with the 4" at least with the plastic version. I wouldn't mind seeing the iPhone go to 16:9, the could fit a 4.5" screen without going any bigger, 4:3 isn't really all that benificial in a phone anyway. I understand the iPad using 4:3 and actually really like the similar aspect ration in the Surface as well but in a phone I don't see much of a difference.
The iPhone has never been 4:3. Originally it was 3:2; it went to 16:9 with the iPhone 5. This is a horrendous aspect ratio for anything but a TV—it's much too narrow in portrait.
That's true. And it sucked. The new 16:9 also sucks, when taking a photo. It's the worst camera one can have since the sensor is 4:3 making a composition very difficult. But I don't see them going to 4:3 for their screen, and making a sensor 16:9 is a big no no. Still, it is the camera that's always with me, so I just need to relax, zoom out and crop afterwards. Which sucks; a photo out to be taken as-is, not altered after the fact.
Comments
Swift continues to change so I doubt serious devs are tackling it. Even IBM. Not until the end of beta. It's a myth that it makes programming for the iPhone or Mac much easier given than the real knowledge you need when programming either is the frameworks.
Can you elaborate on that? Bit difficult to respond with an 'ok, thanks' without you giving any indication as to why. Not asking for proof, obviously, but since it's your opinion I'd like to read why you think this should be taken as truth.
Yes, Swift continues to change -- it is evolving, but it is reasonably stable for a beta. I'd say it is no worse than other new frameworks as far as bugs, work-arounds or learning difficulty.
As I see it, the advantages of Swift are (in no particular order):
Having worked in IBM Development, I think IBM will be all over Swift -- it is a rare opportunity (for both Apple and IBM) to learn from each other, to define/solidify the language, to add features to satisfy the needs of both of their target customers, exploit a competitive advantage and to enhance the appeal of their product and service offerings.to
One final thought -- the ease of coding debugging interactively in Playgrounds then copy/pasting that code into classes for compilation is almost trivial.
For example here's a modification of my earlier example that runs in a Playground.
import UIKit var str = "Hello, playground" class ViewController: UIViewController { @IBOutlet var stockPrice : UILabel! // Add Output field to UIView override func viewDidLoad() { super.viewDidLoad() let url: NSURL = NSURL(string: "http://localhost/aapl"
let aaplPrice: Double = (NSString.stringWithContentsOfURL(url,
encoding:NSASCIIStringEncoding, error:nil)).doubleValue
var label: String = "AAPL Stock price is $\(aaplPrice) "
if aaplPrice >= 100 {label += "????"} else {label += "????"}
println(label)
// stockPrice.text = "\(label) " // Set Output field in UI View
}
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
// Dispose of any resources that can be recreated.
}
}
let myVC = ViewController()
myVC.viewDidLoad()
As you can see, I included the ViewController code in the Playground. All you have to do to execute the code is to create an instance of the VC, then call the viewDidLoad func.
When debugged, you just copy/paste the whole ViewController Class into the class file for compilation.
Note: as implemented, the commented stockPrice.text field causes an error in the Playground because it references an IBOutlet in the UIView. -- it needs to be uncommented for compilation of the ViewController Class.
If you want to see how the UIView actually looks as the Playground is executing, you can write a little extra code to create a UIView and the various fields. I've done this with TableViews, but it's a little too retro for most needs.
However, at some point I expect Apple will integrate Storyboards and Playgrounds -- so you can interactively design and debug your apps.
Ah, ok. Well, if they release a 4.7" screen iPhone that is has a larger FF than the current model I won't be buying it. It's already large enough, some of my pants 'have a problem with it' meaning the phone 'drops landscape' in my pocket and it 'a bit difficult to take out'. Yes, in diacritical mark, because it obviously ISN'T A BIG problem, but still, not preferring a larger phone than it already is.
Nothing in that code which couldn't be done in objective c of course, albeit without the compile error. Most of the work is the frameworks. At the moment swift is unstable in its design, it's philosophy of design in many ways, the debugger, playgrounds, interaction with objective C, the compiler and debugger. Which is a lot.
Is it easier to understand than objective C? Sometimes. Sometimes not. See generics.
They have in many cases - and this is a design philosophy - sacrificed code readability on the alter of code compactness. Which is the opposite of objective C. We'll see. I have plans to write some swift code in my large mac project targeting Yosemite. . I've tried already but code which worked in the playground failed with a compiler exception in the real build. That's not good.
It does reduce potential crashes caused by nil pointers passed into some framework API. Performance is not really obvious.
September used to seem so far away, but just a few more weeks to go. The 4S has been good to me but I'm more than ready to pull the trigger on a new iPhone. The wait is nearly over.
I am going to give myself a 4 week Appleinsider sabbatical because I want to be awed again.
Last year was a bit miserable with all the 5C leaks. There were no surprises left.
if the iPhone mini were to be "the one more thing".
This year I am pleasantly surprised not having seen a finished (part of the) iPhone. We're completely clueless about the design, which is great.
My money is on an unapologetic plastic 3.5" iPhone mini. Mint green would be totally awesome! (One can Dream). I imagine the 5.5" folks going mental
So, that's it folks!
I see you in about a month!
That's wonderful! Let's hope for some good news after Sep. 9 event. Also waiting to see new gadgets from Apple.
I see gomers with these huge slabs held up against the side of their heads and think the phone should have come with that helmet they shouldn't be allowed out of the house without. Does Apple want all of their customers to look like fucking spazzes? Maybe, but I'm not convinced.
Ah, you must be one of those people who insist on trying a new phone on in front of a mirror to see how it looks on you. No, nothing superficial and shallow about that. *snicker*
I wasn't trying to show things that couldn't be done in Obbj-C or vise versa. Rather, I was trying to illustrate the workflow going from interactive debugging to a compiled app. I could have eliminated the compiler error, but I thought it better to be honest and note that you, likely, will have slightly different versions of code in the Playgrounds and in the compiled classes (at least for now).
Yes, most of the work is in the frameworks -- and much of the problems is unlearning the Obj-C way and relearning the Swift way ... It's more than different syntax, its a different approach to the way you attack a task.
I will concede that Swift is somewhat unstable in design -- I think that Apple enjoys (and exploits) the luxury of not having a Swift install base (it's only been available for a little over a month) ... They don't need to deprecate things to protect existing developer code -- They just change things and the devs need to go with the flow.
I expect this evolution/instability to continue until the GM (a week before the iPhone availability) when they will accept Swift apps for the App store.
I, too ran into several cases where code that worked in Playground (ha, almost typed Praygrounds) failed to compile. Before I could submit a bug, beta 5 eliminated the problem.
I have been doing some performance comparisons with > 10K packets coming down the line from a web site/service.
I don't think that Apple has rewritten the JSON serialization/deserialization routines to exploit Swift, yet -- so I don't expect any improvements here -- yet!
But I've been testing an alternative to JSON, XML, etc. -- all that verbose crap. I've been timing building arrays and dictionaries using String, Any and AnyObject. Beta 5 Swift is 1 - 2 orders of magnitude faster in some cases.
This performance should really appeal to IT and IBM who need to shlep around big data.
Here's a post I made to another thread:
What expo? What's it all about? Fill us in.
I'm sure Apple will continue on with the 4" at least with the plastic version. I wouldn't mind seeing the iPhone go to 16:9, the could fit a 4.5" screen without going any bigger, 4:3 isn't really all that benificial in a phone anyway. I understand the iPad using 4:3 and actually really like the similar aspect ration in the Surface as well but in a phone I don't see much of a difference.
I mean have they now, where are the cryptic invitations?
The iPhone has never been 4:3. Originally it was 3:2; it went to 16:9 with the iPhone 5. This is a horrendous aspect ratio for anything but a TV—it's much too narrow in portrait.
I guess they're not the only ones. Why don't you just enlighten us.... thanks.
50,000,000 Samdung Note Phones were sold in the past 2 years.
The market for phablets is way too big to ignore.
That is my proof.
Nope. They are people who are too poor to afford an iPad, so they get a big phone as a compromise instead.
Which, as we know, are available at ALL times, and for ALL uses, to manage your cell phone, regardless of the situation in which you want to use it¡
Just let him be; he'll never grasp the issue at hand.
Yep; he just has no grip on the situation, unlike you, who has a handle on things.
That's true. And it sucked. The new 16:9 also sucks, when taking a photo. It's the worst camera one can have since the sensor is 4:3 making a composition very difficult. But I don't see them going to 4:3 for their screen, and making a sensor 16:9 is a big no no. Still, it is the camera that's always with me, so I just need to relax, zoom out and crop afterwards. Which sucks; a photo out to be taken as-is, not altered after the fact.