For consumers, I would agree, 4K is not yet practical but for editors it is. For the same reason high megapixel still cameras are. If you are targeting 1080, starting with 4K gives you a lot of creative possibilities with zooming, panning and cropping.
4K does offer zooming, panning, cropping. That does not automatically translate into a better picture.
So you want Apple to get in the game of spec whoring? Seriously does the average iOS user even really notice these performance improvements? I'd take more RAM any day over anything else. I'm sure the 6S (or whatever Apple calls it) will be a worthy upgrade for 4S/5/5S owners. Perhaps not so much for 6/6 Plus owners but why people think they need a blow away new phone every year is beyond me.
There are a significant number of people that upgrade every year. It is worth Apple's time, effort, and $$$ to differentiate the "S" models to the best extent they can.
Having said that, this story is only a rumor, and at this point of the cycle it is very likely that Apple has some surprises up their sleeves for this year's model.
You should tell Phil Schiller. He desperately needs to learn how to market iPhones the way he markets the Mac Pro: a naked list of specs.
I strongly disagree. The best differentiator for the iPhone by far is iOS and the ecosystem that together allow us to easily accomplish many things. Same is true of standard Macs and OS X. The only reason to list a bazillion specs for the Mac Pro is to explain why it differs from an iMac or MacBook, etc. The iPhone's hardware won't stand out so much from whatever you are trying to differentiate it from.
Not to the normal people, to the diehards. The ones who gladly splurge for the 128GB model. Personally I'm fine with 1GB but I know some people want 2. (To be fair, it's more of an issue on the iPads)
If the context is marketing, then you are talking about the "normal people", so you can move more units. The diehards you mention will find out about the 2GB RAM regardless and don't need commercials to get them to buy iPhoned.
Did somebody wake up on the wrong side of the bed?
Actually A9 has huge potential if it makes it to 14 nm. It might not be improved in the way you want but 14 nm could allow Apple to integrate much of the external circuitry now seen on iPhone motherboards. This would lead to lower power usage, increased space for battery and flash and greater performance.
Eventually iPhone will become a mature product line and you won't see massive improvements. Once you hit 12 mp for example the pay off for more pixels is minimal for point and shoot users.
What do you care? Seriously ignore the idiots that say such things.
The best feature would likely be more RAM!
What you don't seem to realize is that the lack of RAM is a serious problem on iOS devices especially the iPhone. Even Apple supplied software like Safari suffers from the lack of RAM.
That is possibly the most asinine view of the RAM issue I've every seen.
How is it asinine? I have an iPhone 4, as well. I'm painfully aware that it's not up to the requirements of today's software.
It's not asinine for one very clear reason — when iOS devices only had 512MB of RAM, everyone felt that 1GB would solve everything! Well, here we are at 1GB, and now everybody wants 2GB. Remind me again how my view is asinine? Maybe you think that 2GB is the sweet spot?
I manage over a dozen servers online, and code my own software to run on those servers. I watch resource consumption _very_ carefully. I work painstakingly hard to get the resource usage of my software _down_ so that it runs quickly and more efficiently for my clients. I could have a very different motivation – strictly adding features, and having to rent beefier servers just to power them. But that would be doing my business, and my clients, a disservice. My software is 100x more capable than it was 10 years ago, and yet consumes less RAM and takes up less CPU than the software from those older days. How? Through careful and considerate design, not by tossing more hardware at the problem. So I'm keenly aware that more RAM is not the only solution. It's one solution, just not the only solution.
All of that said, I'll be a very happy camper when I finally retire my iPhone 4 later this year and join the modern crowd, with bigger screens, more features, and more RAM. :P
Ya' know ...
IMO, one of the biggest wastes in iOS and OS X is the system-wide use of XML. It wastes bandwidth, processing time, storage, cell data, RAM and battery power.
For example. I have a small iPhone data source that I use to prime a table on the iPhone and Watch. If stored as a PList or archive file, it is encoded into XML, stored within the app on disk/SSD, decoded from XML into RAM, then processed.
The XML packet is twice the size of a text representation of the file and takes > twice as long to encode or decode. It's even worse if you have to retrieve the data from an external source on a web server.
All for what?
Human readability!
But what humans, except, infrequently, developers, need to look at the datasource for a table ... but every user pays the price.
JSON is somewhat more efficient (about 50% waste), but still ...
Eventually iPhone will become a mature product line and you won't see massive improvements. Once you hit 12 mp for example the pay off for more pixels is minimal for point and shoot users.
The difference between high and low MP on a phone camera is even less important than what you are saying, and even for professional photographers.
Since every lens has a limit of optical resolution, you can only place so many pixels in a small space before you have multiple pixels within the "point spread function" of the lens. Adding more pixels than that only gives you more "blurry pixels" and no additional information.
Here's the point: for a lens as small in diameter as most phones (including iPhone) the point spread function of the lens has been the limiting factor on spatial resolution ever since the sensors went passed 5 MP or so. Apple would be better off working on the qualities of the lens, optical image stabilization, and the low light performance (like this RGBW concept). I do love how Apple is moving with regard to this stuff lately, but moving up to 12 MP from 8 MP will not improve the quality of the image in the least unless the lens gets larger in diameter.
IMO, one of the biggest wastes in iOS and OS X is the system-wide use of XML. It wastes bandwidth, processing time, storage, cell data, RAM and battery power.
For example. I have a small iPhone data source that I use to prime a table on the iPhone and Watch. If stored as a PList or archive file, it is encoded into XML, stored within the app on disk/SSD, decoded from XML into RAM, then processed.
The XML packet is twice the size of a text representation of the file and takes > twice as long to encode or decode. It's even worse if you have to retrieve the data from an external source on a web server.
All for what?
Human readability!
But what humans, except, infrequently, developers, need to look at the datasource for a table ... but every user pays the price.
JSON is somewhat more efficient (about 50% waste), but still ...
There are signs that Apple is adopting the use of JSON more and more, which is good. Apple also (very occasionally) implements binary representations of certain XML files, when the file can be large and performance is absolutely essential, such as the iTunes Library.
I agree with you, and I hope that Apple developers really push performance and efficiency with 10.11 and iOS 9. When first developing the iPhone OS (which became iOS), employing strictness on file size and raw execution performance was a top priority. I think if they return to that focus, we will have unbelievably operating systems, both in features and performance that the competition can't even touch!
Anybody with a clue when it comes to computer technology realizes that iOS devices need more RAM. If I phone adds more RAM Apple wouldn't need to advertise the fact as the news would spread like wildfire.
I agree that iOS needs more RAM, but the people that need to get their information from advertising are the same people that the RAM information will fly right past. For you and the others that appreciate the implications of more RAM, you'll get the information anyway without watching commercials. That information won't spread like "wildfire" through the masses because of marketing. It may spread like "wildfire" through geeks like us because we follow this stuff.
IMO, one of the biggest wastes in iOS and OS X is the system-wide use of XML. It wastes bandwidth, processing time, storage, cell data, RAM and battery power.
JSON is somewhat more efficient (about 50% waste), but still ...
Also – this is huge – Apple purchased FoundationDB earlier this year... a high-performance key-value storage technology. I had just learned about FoundationDB the week prior to this news, and was saddened when I would no longer be able to employ it in my business. But for it to become a key element to a high-performance OS X and iOS makes me very excited.
If the context is marketing, then you are talking about the "normal people", so you can move more units. The diehards you mention will find out about the 2GB RAM regardless and don't need commercials to get them to buy iPhoned.
Even once it is, 1080 is probably "retina level" at the kinds of viewing distances most people watch a 50 inch TV from. So if you add more content, it still wouldn't matter.
It was the immediate context of the sub-thread your post was on. Go back and check the post you responded to, your response, and my answer. Seems like a reasonable thread of discussion to me.
IMO, one of the biggest wastes in iOS and OS X is the system-wide use of XML. It wastes bandwidth, processing time, storage, cell data, RAM and battery power.
JSON is somewhat more efficient (about 50% waste), but still ...
Also – this is huge – Apple purchased FoundationDB earlier this year... a high-performance key-value storage technology. I had just learned about FoundationDB the week prior to this news, and was saddened when I would no longer be able to employ it in my business. But for it to become a key element to a high-performance OS X and iOS makes me very excited.
Yeah! A hash, used properly, can be a very efficient way to store and manipulate (retrieve, process, scale, distribute) data.
The keys should be few, meaningful and unique.
The values should be concise and encoded for their primary usage (streaming, query, transactions, etc.).
... And, of course a value can always contain additional hashes ;)
IMO, one of the biggest wastes in iOS and OS X is the system-wide use of XML. It wastes bandwidth, processing time, storage, cell data, RAM and battery power.
For example. I have a small iPhone data source that I use to prime a table on the iPhone and Watch. If stored as a PList or archive file, it is encoded into XML, stored within the app on disk/SSD, decoded from XML into RAM, then processed.
The XML packet is twice the size of a text representation of the file and takes > twice as long to encode or decode. It's even worse if you have to retrieve the data from an external source on a web server.
All for what?
Human readability!
But what humans, except, infrequently, developers, need to look at the datasource for a table ... but every user pays the price.
JSON is somewhat more efficient (about 50% waste), but still ...
plist, xml and JSON are all used for different purposes and are not necessarily interchangeable in all circumstances. The biggest advantage of XML is not the human readability but instead the ubiquitous compatibility of it. XML parsing is universally supported. Plists are generally used for UNIX-like app configuration parameters when first launched. Not a very good format for data interchange communications. JSON is most useful for request response communication and handling errors within the communication. Similar to XML but more specialized. JSON doesn't keep the requests in order, is only used in http or tcp protocols and does not nest key pairs like XML. In my opinion XML is an excellent data format for general purposes which is probably why it is so widely used.
plist, xml and JSON are all used for different purposes and are not necessarily interchangeable in all circumstances. The biggest advantage of XML is not the human readability but instead the ubiquitous compatibility of it. XML parsing is universally supported. Plists are generally used for UNIX-like app configuration parameters when first launched. Not a very good format for data interchange communications. JSON is most useful for request response communication and handling errors within the communication. Similar to XML but more specialized. JSON doesn't keep the request in order and does not nest key pairs like XML. In my opinion XML is an excellent data format for general purposes which is probably why it is so widely used.
I agree that they are used for different purposes.
But, I think ubiquity and universal availability of XML parsers has made programmers lazy. When you write an app, you decide on the format and content of your data pretty early in the design cycle. After that, it changes infrequently -- say, a new version of the app with additional records and fields.
But, every time anyone uses the app they are spending an enormous amount of overhead for the luxury of using XML.
In my prior table datasource example, the data is stored as a string, The string takes 503 characters.
When you encapsulate this single string into an XML packet, the size of the XML packet balloons 996 characters,
Each datasource/model record consists of 4 fields represented as strings:
Quantity: Int32
Item name: String
Price: Float
Special: Bool
If these records/fields were encoded into an XML packet it would take several thousands of bytes ... been down that path before & won't bother with the exercise, again!
It takes 1 iOS/OSX instruction less than .01 second to parse the String representation.
It takes who-knows-how-many instructions more than 1 second to unwrap the single string from the encapsulating XML packet.
This is pretty important because the datasource/model is frequently passed between the iPhone and Watch Extension. An even more efficient way, when possible, it to just pass the Quantity fields.
The difference, when running on the Watch and and iPhone is quite noticeable in time, battery, Storage and RAM usage -- well performing vs unacceptable!
All because the format and content of the data is known in advance rather having to be reinvented every time it is referenced.
Comments
WTF? I have a 4K 32" monitor and 4K material looks fantastic!
For a movie-theater experience, I sit 6 feet from my 1080p set and wish it were 4K, which still might not be enough. I don't want to see pixels ever.
The far majority of content you are watching is scaled 1080P, if you are watching broadcast television you are watching scaled 720P.
4K is probably not worth the costs on a 50" TV unless you sit uncomfortably close.
Who is the 5K 27" iMac retina targeted at? Consumers.
The 5K iMac is largely targeted at professional video editors, photo editors, and graphic designers.
Doesn't seem like that would be difficult to understand.
For consumers, I would agree, 4K is not yet practical but for editors it is. For the same reason high megapixel still cameras are. If you are targeting 1080, starting with 4K gives you a lot of creative possibilities with zooming, panning and cropping.
4K does offer zooming, panning, cropping. That does not automatically translate into a better picture.
There are a significant number of people that upgrade every year. It is worth Apple's time, effort, and $$$ to differentiate the "S" models to the best extent they can.
Having said that, this story is only a rumor, and at this point of the cycle it is very likely that Apple has some surprises up their sleeves for this year's model.
4K is probably not worth the costs on a 50" TV unless you sit uncomfortably close.
I strongly disagree. The best differentiator for the iPhone by far is iOS and the ecosystem that together allow us to easily accomplish many things. Same is true of standard Macs and OS X. The only reason to list a bazillion specs for the Mac Pro is to explain why it differs from an iMac or MacBook, etc. The iPhone's hardware won't stand out so much from whatever you are trying to differentiate it from.
If the context is marketing, then you are talking about the "normal people", so you can move more units. The diehards you mention will find out about the 2GB RAM regardless and don't need commercials to get them to buy iPhoned.
Ya' know ...
IMO, one of the biggest wastes in iOS and OS X is the system-wide use of XML. It wastes bandwidth, processing time, storage, cell data, RAM and battery power.
For example. I have a small iPhone data source that I use to prime a table on the iPhone and Watch. If stored as a PList or archive file, it is encoded into XML, stored within the app on disk/SSD, decoded from XML into RAM, then processed.
The XML packet is twice the size of a text representation of the file and takes > twice as long to encode or decode. It's even worse if you have to retrieve the data from an external source on a web server.
All for what?
Human readability!
But what humans, except, infrequently, developers, need to look at the datasource for a table ... but every user pays the price.
JSON is somewhat more efficient (about 50% waste), but still ...
The difference between high and low MP on a phone camera is even less important than what you are saying, and even for professional photographers.
Since every lens has a limit of optical resolution, you can only place so many pixels in a small space before you have multiple pixels within the "point spread function" of the lens. Adding more pixels than that only gives you more "blurry pixels" and no additional information.
Here's the point: for a lens as small in diameter as most phones (including iPhone) the point spread function of the lens has been the limiting factor on spatial resolution ever since the sensors went passed 5 MP or so. Apple would be better off working on the qualities of the lens, optical image stabilization, and the low light performance (like this RGBW concept). I do love how Apple is moving with regard to this stuff lately, but moving up to 12 MP from 8 MP will not improve the quality of the image in the least unless the lens gets larger in diameter.
Ya' know ...
IMO, one of the biggest wastes in iOS and OS X is the system-wide use of XML. It wastes bandwidth, processing time, storage, cell data, RAM and battery power.
For example. I have a small iPhone data source that I use to prime a table on the iPhone and Watch. If stored as a PList or archive file, it is encoded into XML, stored within the app on disk/SSD, decoded from XML into RAM, then processed.
The XML packet is twice the size of a text representation of the file and takes > twice as long to encode or decode. It's even worse if you have to retrieve the data from an external source on a web server.
All for what?
Human readability!
But what humans, except, infrequently, developers, need to look at the datasource for a table ... but every user pays the price.
JSON is somewhat more efficient (about 50% waste), but still ...
There are signs that Apple is adopting the use of JSON more and more, which is good. Apple also (very occasionally) implements binary representations of certain XML files, when the file can be large and performance is absolutely essential, such as the iTunes Library.
I agree with you, and I hope that Apple developers really push performance and efficiency with 10.11 and iOS 9. When first developing the iPhone OS (which became iOS), employing strictness on file size and raw execution performance was a top priority. I think if they return to that focus, we will have unbelievably operating systems, both in features and performance that the competition can't even touch!
I agree that iOS needs more RAM, but the people that need to get their information from advertising are the same people that the RAM information will fly right past. For you and the others that appreciate the implications of more RAM, you'll get the information anyway without watching commercials. That information won't spread like "wildfire" through the masses because of marketing. It may spread like "wildfire" through geeks like us because we follow this stuff.
Ya' know ...
IMO, one of the biggest wastes in iOS and OS X is the system-wide use of XML. It wastes bandwidth, processing time, storage, cell data, RAM and battery power.
JSON is somewhat more efficient (about 50% waste), but still ...
Also – this is huge – Apple purchased FoundationDB earlier this year... a high-performance key-value storage technology. I had just learned about FoundationDB the week prior to this news, and was saddened when I would no longer be able to employ it in my business. But for it to become a key element to a high-performance OS X and iOS makes me very excited.
If the context is marketing, then you are talking about the "normal people", so you can move more units. The diehards you mention will find out about the 2GB RAM regardless and don't need commercials to get them to buy iPhoned.
Where did I say anything about marketing?
Even once it is, 1080 is probably "retina level" at the kinds of viewing distances most people watch a 50 inch TV from. So if you add more content, it still wouldn't matter.
It was the immediate context of the sub-thread your post was on. Go back and check the post you responded to, your response, and my answer. Seems like a reasonable thread of discussion to me.
Yeah! A hash, used properly, can be a very efficient way to store and manipulate (retrieve, process, scale, distribute) data.
The keys should be few, meaningful and unique.
The values should be concise and encoded for their primary usage (streaming, query, transactions, etc.).
... And, of course a value can always contain additional hashes ;)
Ya' know ...
IMO, one of the biggest wastes in iOS and OS X is the system-wide use of XML. It wastes bandwidth, processing time, storage, cell data, RAM and battery power.
For example. I have a small iPhone data source that I use to prime a table on the iPhone and Watch. If stored as a PList or archive file, it is encoded into XML, stored within the app on disk/SSD, decoded from XML into RAM, then processed.
The XML packet is twice the size of a text representation of the file and takes > twice as long to encode or decode. It's even worse if you have to retrieve the data from an external source on a web server.
All for what?
Human readability!
But what humans, except, infrequently, developers, need to look at the datasource for a table ... but every user pays the price.
JSON is somewhat more efficient (about 50% waste), but still ...
plist, xml and JSON are all used for different purposes and are not necessarily interchangeable in all circumstances. The biggest advantage of XML is not the human readability but instead the ubiquitous compatibility of it. XML parsing is universally supported. Plists are generally used for UNIX-like app configuration parameters when first launched. Not a very good format for data interchange communications. JSON is most useful for request response communication and handling errors within the communication. Similar to XML but more specialized. JSON doesn't keep the requests in order, is only used in http or tcp protocols and does not nest key pairs like XML. In my opinion XML is an excellent data format for general purposes which is probably why it is so widely used.
I agree that they are used for different purposes.
But, I think ubiquity and universal availability of XML parsers has made programmers lazy. When you write an app, you decide on the format and content of your data pretty early in the design cycle. After that, it changes infrequently -- say, a new version of the app with additional records and fields.
But, every time anyone uses the app they are spending an enormous amount of overhead for the luxury of using XML.
In my prior table datasource example, the data is stored as a string, The string takes 503 characters.
When you encapsulate this single string into an XML packet, the size of the XML packet balloons 996 characters,
Each datasource/model record consists of 4 fields represented as strings:
If these records/fields were encoded into an XML packet it would take several thousands of bytes ... been down that path before & won't bother with the exercise, again!
It takes 1 iOS/OSX instruction less than .01 second to parse the String representation.
It takes who-knows-how-many instructions more than 1 second to unwrap the single string from the encapsulating XML packet.
This is pretty important because the datasource/model is frequently passed between the iPhone and Watch Extension. An even more efficient way, when possible, it to just pass the Quantity fields.
The difference, when running on the Watch and and iPhone is quite noticeable in time, battery, Storage and RAM usage -- well performing vs unacceptable!
All because the format and content of the data is known in advance rather having to be reinvented every time it is referenced.