To clear this up, let me explain how DRAM works. Most people should know this, but apparently the lesson has been forgotten.
Dynamic RAM needs to be refreshed every few milliseconds. That uses power. It's not like NAND used for storage. Even if there is nothing in DRAM, it still needs to be refreshed. DRAM can need heatsinks because it can get hot, in high performance modules. This uses power. Where does power come from in mobile devices? Yes, batteries. How much power gets used depends on how much RAM there is, and what kind of RAM. It doesn't use a huge amount of power at once, but it's always drawing power.
That article is decent, but woefully incomplete.
I know how DRAM works, I just don't by that 1GB more would have put such a large dent in battery life that Apple had no choice but to omit it. Memory is not one of the major battery draining components in a smart phone, regardless if it is always drawing power.The articles pertaining to what the major factors are to power consumption in a smart phone, like every other I have read doesn't discuss memory because of how little impact it actually has on the overall power scheme.
I have not seen any response on pricing, availability, yields, quantities in stock available, etc. between a 1GB module and a 2GB module.
It seems that everyone, including you, is not taking into consideration that a 2GB module might be significantly higher in cost, not available in the quantities that Apple needs, the production yields are very low thereby restricting the number of iPhone 6 units that can be built, there were small quantities available in stock, etc. and would not have allowed Apple to ship the number of units that Apple anticipated it would need for the launch of the iPhone 6.
If that is the case and Apple was to use a 2GB module and iPhone 6 was delayed or shipped in small quantities - what would your response be? Apple should have waited to get it right - Apple is waiting too long to release a new phone, Apple does not know what it is doing ...
It seems that you are not open to the possibility that there may have been a issue with procuring 2GB modules for the amount of iPhone 6 units that Apple anticipated it needs at launch and as such Apple did not use a 2GB module.
Actually my whole point in the beginning was that Apple didn't use 2GB because of costs, no, I'm fighting the whole idea that 2GB draws too much power, maybe once you start getting above 4GB but not 2GB. I haven't seen any literature or articles to suggest that it does, it would be a major design flaw if it was true as it would mean we would never see more than 1GB or face a thicker iPhone because the battery would have to be larger. I have read pretty much everything I can get my hands on pertaining to the A7 and A8 CPU, nothing about memory being a battery killer that people are suggesting here. Am I missing something, do you have a piece of technical literature that I can reference here to set me straight?
I know how DRAM works, I just don't by that 1GB more would have put such a large dent in battery life that Apple had no choice but to omit it. Memory is not one of the major battery draining components in a smart phone, regardless if it is always drawing power.The articles pertaining to what the major factors are to power consumption in a smart phone, like every other I have read doesn't discuss memory because of how little impact it actually has on the overall power scheme.
It doesn't need to put a large dent into battery life. All design is a tradeoff. This would be just one thing in many affecting battery life, and as such, was likely considered. When I designed equipment, memory draw was always a consideration. Whether or not you want to believe it, it was very likely a consideration for Apple as well.
Now more apps can run more tasks, different tasks.
I do not believe that iOS apps can run more tasks without restrictions (which is how I read your comment - i.e. the developer just decide what runs in the background regardless of the task) - rather that Apple has increased the number of allowed background tasks and how to use them rather specifically.
If that is what you meant - please excuse the following ... but it may be of interest.
Apple’s Guidance on What/How to Efficiently Run Your App In The Background
When you find it necessary to keep your app running in the background, iOS helps you do so efficiently and without draining system resources or the user’s battery. The techniques offered by iOS fall into three categories:
Apps that start a short task in the foreground can ask for time to finish that task when the app moves to the background.
Apps that initiate downloads in the foreground can hand off management of those downloads to the system, thereby allowing the app to be suspended or terminated while the download continues.
Apps that need to run in the background to support specific types of tasks can declare their support for one or more background execution modes.
List of Long-Running Tasks
In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background, such as a music player app Apps that record audio content while in the background
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Apps that need to download and process new content regularly Apps that receive regular updates from external accessories
Another (to what is me) Clear Overview/Explanation of how iOS implements/allows for background tasks
A Change To Background Execution
There is a fundamental change in the way that iOS now handles background execution. Instead of allowing background tasks to start and run to completion or simply get terminated by iOS, execution will occur in bursts.
The idea behind this is to preserve battery life. When the user either backgrounds an app or locks their screen, they may or may not have additional time to run their background task. Also, the schedule that will be used to perform the background fetches is mostly determined by iOS. iOS will keep task execution at a minimum while the device is locked and tasks will be woken up and allowed to execute in groups. For example, when Mail is ready to check for e-mail or when a notification arrives, iOS will wake up other processes to run for a particular amount of time, then the processes will go quiet again.
Using this scheme, iOS is able to provide better battery life since the device will be quiet for certain periods of time and then handle multiple tasks during each wake up period. This is in contrast to the model for iOS 6 where apps will allowed to run background tasks, even after the user locked their device, and other processes would run given their independent polling cycle without coordination.
Background Fetching
The first new API change we'll cover is the background fetch. For this feature, iOS will monitor how the user uses your app and will periodically "wake up" your app in order to perform a fetch. This is an opportunity for your app to retrieve information from a remote service to be used in your app and displayed to the user. This keeps your app data fresh and reduces the amount of time it takes for the user to be able to interact with it.
One important detail to keep in mind is that you as a developer don't have much control as to when iOS will call upon your app to fetch the data. You can set the minimum interval time, but that is all. This minimal interval time tells iOS how frequently it makes sense to perform the fetch. You must set this value since it will default to UIApplicationBackgroundFetchInternalNone, which tells iOS to never perform a background fetch.
In most circumstances, you will want to set this value to be the minimum, which tells iOS to uses its best judgment as to when to perform the update based on how the user uses the app. In your app, set this value in the application:didFinishLaunchingWithOptions: method in your AppDelegate class.
Now trying to cover the above and the comments about system RAM quantity …
Admittedly this is only a small sample of documentation but I see a common thread here - write your App to preserve battery life and suspend your App so it does not take up processor cycles and/or memory space.
Using the above “common thread” where does it say that Apple choses what to put in an iPhone based on price?
My belief is that they did not need 2GB system RAM for a good general user (the percentage of which is always larger than Pro users) experience - specifically battery life and Apple was able to secure a set price and steady supply of quality 1GB system RAM modules, and a huge number in stock (so they do not run out in the middle of supplying their customers - again 4M is not a huge number). A huge number would be at least 30M - you need to have some for the production lines, account for those in transit, those in inventory, those waiting to be produced.
I suspect that the 2GB system RAM module was either constrained in quantity (lower quantity generally means higher price) or quality (if you need to have an iPhone returned because the RAM has failed - that is not a good thing for a good general user and critical for a Pro user).
I do not believe that iOS apps can run more tasks without restrictions (which is how I read your comment - i.e. the developer just decide what runs in the background regardless of the task) - rather that Apple has increased the number of allowed background tasks and how to use them rather specifically.
If that is what you meant - please excuse the following ... but it may be of interest.
Apple’s Guidance on What/How to Efficiently Run Your App In The Background
When you find it necessary to keep your app running in the background, iOS helps you do so efficiently and without draining system resources or the user’s battery. The techniques offered by iOS fall into three categories:
Apps that start a short task in the foreground can ask for time to finish that task when the app moves to the background.
Apps that initiate downloads in the foreground can hand off management of those downloads to the system, thereby allowing the app to be suspended or terminated while the download continues.
Apps that need to run in the background to support specific types of tasks can declare their support for one or more background execution modes.
List of Long-Running Tasks
In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background, such as a music player app Apps that record audio content while in the background
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Apps that need to download and process new content regularly Apps that receive regular updates from external accessories
Another (to what is me) Clear Overview/Explanation of how iOS implements/allows for background tasks
A Change To Background Execution
There is a fundamental change in the way that iOS now handles background execution. Instead of allowing background tasks to start and run to completion or simply get terminated by iOS, execution will occur in bursts.
The idea behind this is to preserve battery life. When the user either backgrounds an app or locks their screen, they may or may not have additional time to run their background task. Also, the schedule that will be used to perform the background fetches is mostly determined by iOS. iOS will keep task execution at a minimum while the device is locked and tasks will be woken up and allowed to execute in groups. For example, when Mail is ready to check for e-mail or when a notification arrives, iOS will wake up other processes to run for a particular amount of time, then the processes will go quiet again.
Using this scheme, iOS is able to provide better battery life since the device will be quiet for certain periods of time and then handle multiple tasks during each wake up period. This is in contrast to the model for iOS 6 where apps will allowed to run background tasks, even after the user locked their device, and other processes would run given their independent polling cycle without coordination.
Background Fetching
The first new API change we'll cover is the background fetch. For this feature, iOS will monitor how the user uses your app and will periodically "wake up" your app in order to perform a fetch. This is an opportunity for your app to retrieve information from a remote service to be used in your app and displayed to the user. This keeps your app data fresh and reduces the amount of time it takes for the user to be able to interact with it.
One important detail to keep in mind is that you as a developer don't have much control as to when iOS will call upon your app to fetch the data. You can set the minimum interval time, but that is all. This minimal interval time tells iOS how frequently it makes sense to perform the fetch. You must set this value since it will default to UIApplicationBackgroundFetchInternalNone, which tells iOS to never perform a background fetch.
In most circumstances, you will want to set this value to be the minimum, which tells iOS to uses its best judgment as to when to perform the update based on how the user uses the app. In your app, set this value in the application:didFinishLaunchingWithOptions: method in your AppDelegate class.
Now trying to cover the above and the comments about system RAM quantity …
Admittedly this is only a small sample of documentation but I see a common thread here - write your App to preserve battery life and suspend your App so it does not take up processor cycles and/or memory space.
Using the above “common thread” where does it say that Apple choses what to put in an iPhone based on price?
My belief is that they did not need 2GB system RAM for a good general user (the percentage of which is always larger than Pro users) experience - specifically battery life and Apple was able to secure a set price and steady supply of quality 1GB system RAM modules, and a huge number in stock (so they do not run out in the middle of supplying their customers - again 4M is not a huge number). A huge number would be at least 30M - you need to have some for the production lines, account for those in transit, those in inventory, those waiting to be produced.
I suspect that the 2GB system RAM module was either constrained in quantity (lower quantity generally means higher price) or quality (if you need to have an iPhone returned because the RAM has failed - that is not a good thing for a good general user and critical for a Pro user).
A huge number in stock and/or able to be produced quickly at the set price and quality becomes EVEN MORE important (if the analysts predictions are correct) when you are going to sell 200M in 90 days.
It doesn't need to put a large dent into battery life. All design is a tradeoff. This would be just one thing in many affecting battery life, and as such, was likely considered. When I designed equipment, memory draw was always a consideration. Whether or not you want to believe it, it was very likely a consideration for Apple as well.
I'm sure it was a consideration, everything is when you are designing a new gadget, that's just logical, the real question is though and I have yet to see any real answer yet, except for guessing, does 2GB of RAM draw too much power from the battery and I honestly don't think so. Memory power consumption has never been an issue before nor was it even given as an excuse when Apple didn't use 2GB in the iPhone 5, 5c, 5s, iPad Air or iPad Air Mini. I would have rather Apple stayed with the A7 and upped the RAM to 2GB if it was, the A7 is still more than capable. But I don't think it's an issue and will continue being thick headed about it until I see any real proof to contrary. I think it was about pricing, maybe even supply constraints, again, I just hope the new iPad Air will have 2GB.
I do not believe that iOS apps can run more tasks without restrictions (which is how I read your comment - i.e. the developer just decide what runs in the background regardless of the task) - rather that Apple has increased the number of allowed background tasks and how to use them rather specifically.
If that is what you meant - please excuse the following ... but it may be of interest.
Apple’s Guidance on What/How to Efficiently Run Your App In The Background
When you find it necessary to keep your app running in the background, iOS helps you do so efficiently and without draining system resources or the user’s battery. The techniques offered by iOS fall into three categories:
Apps that start a short task in the foreground can ask for time to finish that task when the app moves to the background.
Apps that initiate downloads in the foreground can hand off management of those downloads to the system, thereby allowing the app to be suspended or terminated while the download continues.
Apps that need to run in the background to support specific types of tasks can declare their support for one or more background execution modes.
List of Long-Running Tasks
In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background, such as a music player app Apps that record audio content while in the background
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Apps that need to download and process new content regularly Apps that receive regular updates from external accessories
Another (to what is me) Clear Overview/Explanation of how iOS implements/allows for background tasks
A Change To Background Execution
There is a fundamental change in the way that iOS now handles background execution. Instead of allowing background tasks to start and run to completion or simply get terminated by iOS, execution will occur in bursts.
The idea behind this is to preserve battery life. When the user either backgrounds an app or locks their screen, they may or may not have additional time to run their background task. Also, the schedule that will be used to perform the background fetches is mostly determined by iOS. iOS will keep task execution at a minimum while the device is locked and tasks will be woken up and allowed to execute in groups. For example, when Mail is ready to check for e-mail or when a notification arrives, iOS will wake up other processes to run for a particular amount of time, then the processes will go quiet again.
Using this scheme, iOS is able to provide better battery life since the device will be quiet for certain periods of time and then handle multiple tasks during each wake up period. This is in contrast to the model for iOS 6 where apps will allowed to run background tasks, even after the user locked their device, and other processes would run given their independent polling cycle without coordination.
Background Fetching
The first new API change we'll cover is the background fetch. For this feature, iOS will monitor how the user uses your app and will periodically "wake up" your app in order to perform a fetch. This is an opportunity for your app to retrieve information from a remote service to be used in your app and displayed to the user. This keeps your app data fresh and reduces the amount of time it takes for the user to be able to interact with it.
One important detail to keep in mind is that you as a developer don't have much control as to when iOS will call upon your app to fetch the data. You can set the minimum interval time, but that is all. This minimal interval time tells iOS how frequently it makes sense to perform the fetch. You must set this value since it will default to UIApplicationBackgroundFetchInternalNone, which tells iOS to never perform a background fetch.
In most circumstances, you will want to set this value to be the minimum, which tells iOS to uses its best judgment as to when to perform the update based on how the user uses the app. In your app, set this value in the application:didFinishLaunchingWithOptions: method in your AppDelegate class.
Now trying to cover the above and the comments about system RAM quantity …
Admittedly this is only a small sample of documentation but I see a common thread here - write your App to preserve battery life and suspend your App so it does not take up processor cycles and/or memory space.
Using the above “common thread” where does it say that Apple choses what to put in an iPhone based on price?
My belief is that they did not need 2GB system RAM for a good general user (the percentage of which is always larger than Pro users) experience - specifically battery life and Apple was able to secure a set price and steady supply of quality 1GB system RAM modules, and a huge number in stock (so they do not run out in the middle of supplying their customers - again 4M is not a huge number). A huge number would be at least 30M - you need to have some for the production lines, account for those in transit, those in inventory, those waiting to be produced.
I suspect that the 2GB system RAM module was either constrained in quantity (lower quantity generally means higher price) or quality (if you need to have an iPhone returned because the RAM has failed - that is not a good thing for a good general user and critical for a Pro user).
Really nice writeup, thank you, I would love to see an override feature for when the iPad is plugged in to allow more to be ran in the background. The iPad is so close to being a really great tool for me, I just need those restrictions lifted so I can run just a few music production apps at once, oh and more memory of course. If not, will have to buy another iPad, maybe 2 more or start using my Surface 3 a lot more.
That of course is your prerogative, but I just can't believe that Apple's engineers were unable to come up with an elegant solution to accommodate 2GB of memory because of power drain. That would suggest bad design, inadequate battery size, heck even a lack of knowledge on the matter and there is no way Apple is incompetent, what, that's really what you're suggesting here. Antagonist, "Oh man, not again, Apple couldn't figure out how to install 2GB of memory in their new iPhone this time around either, oh well, maybe next year". Anyway, would love to see any technical literature stating that having 2GB of RAM in your phone would cause anything but a negligible amount of power loss. As it just doesn't seem like a valid excuse to me, especially when I have phones with 2GB of memory that seem to be unaffected in any real manner because of it. In fact in every single article I've read in the last three days, which has now surpassed 30, about what affects battery life in a modern smartphone, not a single one mentioned that memory was a big factor, heck none even mentioned memory. Yes of course everything with a current in the phone will cause the battery to drain but memory size is not a major factor. I honest don't care about the iPhone but I was greatly anticipating that the iPad would have 2GB of memory, unfortunately the new iPhone took away a lot of that hope.
I'm going to start posting every good article I can find about battery usage here;
To clear this up, let me explain how DRAM works. Most people should know this, but apparently the lesson has been forgotten.
Dynamic RAM needs to be refreshed every few milliseconds. That uses power. It's not like NAND used for storage. Even if there is nothing in DRAM, it still needs to be refreshed. DRAM can need heatsinks because it can get hot, in high performance modules. This uses power. Where does power come from in mobile devices? Yes, batteries. How much power gets used depends on how much RAM there is, and what kind of RAM. It doesn't use a huge amount of power at once, but it's always drawing power.
That article is decent, but woefully incomplete.
I read the article too and it is inadequate. The writer had his/her eye set on gross power consumption points and was totally oblivious to all the smaller places where power is used.
Actually my whole point in the beginning was that Apple didn't use 2GB because of costs, no, I'm fighting the whole idea that 2GB draws too much power, maybe once you start getting above 4GB but not 2GB. I haven't seen any literature or articles to suggest that it does, it would be a major design flaw if it was true as it would mean we would never see more than 1GB or face a thicker iPhone because the battery would have to be larger. I have read pretty much everything I can get my hands on pertaining to the A7 and A8 CPU, nothing about memory being a battery killer that people are suggesting here. Am I missing something, do you have a piece of technical literature that I can reference here to set me straight?
Unfortunately I do not have any reference material in regards to battery life between 1GB system RAM and 2GB system RAM (as no iPhone I am aware of has that amount) on an iPhone.
I think that using reference material for other OS will not allow us to draw the proper conclusions since they use a different model of how the OS handles everything.
Perhaps both of us can look to see if there is some reference material in regards to battery life between 512MB system RAM (IFC iPhone 5 used that amount) and 1GB system RAM (IRC iPhone 5s used/uses that amount) on an iPhone. That should provide solid material on which to draw an informed theory since it is same OS and similar hardware.
If we find that reference material then we could probably discard the changes implemented between versions greater than iOS 7 and stipulate that there are the same so we do not get distracted in the minute details - I think a broad theory works ...
It has always been my belief that Apple chose 1GB system RAM for several reasons (I cannot provide documentation since I could not find any and I am not privy to the design/cost/delivery/sales considerations that go into an iPhone launch) is that they looked at all system RAM configurations/types and decided that the best value to Apple and its customers was to chose an amount that they knew had the quality, quantity, stock inventory, and ability to be produced quickly at set quality and price for an huge number (200M if the analysts are correct - even 150M) over at least four quarters and that turned out to be 1GB system RAM.
Really nice writeup, thank you, I would love to see an override feature for when the iPad is plugged in to allow more to be ran in the background. The iPad is so close to being a really great tool for me, I just need those restrictions lifted so I can run just a few music production apps at once, oh and more memory of course. If not, will have to buy another iPad, maybe 2 more or start using my Surface 3 a lot more.
While that would be great for iPad users it would start a split in user experience (spilt personality) for iOS devices. Oh the iPhone does not do that but the iPad does ... that could quickly lead to confusion, frustration, etc. for the general user.
I firmly believe that Apple would want to avoid a spilt personality at all costs - even taking bad press because I believe a unified user experience in a particular OS (iOS and OS X have distinct user personalities but share common broad general ways of doing things - i.e. Notifications in both, lack of touch in OS X and lack of mouse support in iOS, common look of dialog boxes and user interface in both) is paramount to Apple.
One can only look at Microsoft and Windows 8 to see what can happen when you allow "split personalities". Metro is completely different than the desktop interface and you can switch between them. How confusing is that?
I do not believe the general user would not understand much less accept that from Apple.
I believe a large number of general users appreciate that the interface and how things work are the same on the iPhone and iPad and that Apple did not expose the OS X interface on those devices which would lead to confusion and fear.
And yes I understand catering to the general user usually means it sucks for a Pro user - but I think we have to accept that this is the way it is for Apple.
Apple has avoided changing its culture just so that it can sell more devices in the Enterprise so I think we can safely run with that it is "the average consumer first, everyone else last" as the motivation for device/design/specification/user experience decisions at Apple.
And if Apple keeps following that motivation then the money will come in since each consumer can individually (versus the Enterprise) purchase/not purchase an Apple device. If general users do not buy enough then everyone at Apple does not get to come to work each day.
With the iPhone 5s, Apple moved from 1 Gb of 32-bit RAM to 1 Gb of 64-bit RAM. While THIS alone doubled the number of transistors to make up 1 Gb of memory. Perhaps Apple is doing some tricks to use both word sizes within RAM? Many things the GPU does won't require 64-bit addressing any way one looks at it. Furthermore, as more apps require 64-bit memory addressing, the ratio of shorter words in memory will lessen. By then Apple could move to a longer word CPU, increase the mixed word-length storage and complete one more transition to more powerful hardware without leaving anyone behind, except, of course, various Luddites who are proud of what they can accomplish with an original iPhone and a paper clip - when the humidity is especially high.
A GB is a GB regardless of the memory width, because that capital "B" stands for byte, which is 8 bits. All memory is called out in bytes. If it's Gb, with the lower case "b", then it stands for bit, which is one eights byte (eight bits in a byte). So you may read about a 128Gb chip, which is a 16GB chip.
If you read about a 32 bit memory path, or lane, that doesn't mean more memory, just how it's organized. The same thing is true of 64 bit memory path.
I'm not arguing about a Gb being a Gb. I'm saying a Gb with a 32-bit path has the half the transistors, flip flops, or mojo as a Gb chip with a 64-bit path. if you have a RAM chip with a certain memory capacity, then that capacity is based on the chip being used at a certain word size.
You cannot take a one-Gb chip and decide to have twice the word length without halving the word count. THAT'S my point.
For Apple to increase their word length to 64-bit, they needed to DO SOMETHING to the supplied memory if they also did not decrease the RAM size stated in NUMBER of memory words. Capisce??
Really nice writeup, thank you, I would love to see an override feature for when the iPad is plugged in to allow more to be ran in the background. The iPad is so close to being a really great tool for me, I just need those restrictions lifted so I can run just a few music production apps at once, oh and more memory of course. If not, will have to buy another iPad, maybe 2 more or start using my Surface 3 a lot more.
While that would be great for iPad users it would start a split in user experience (spilt personality) for iOS devices. Oh the iPhone does not do that but the iPad does ... that could quickly lead to confusion, frustration, etc. for the general user.
I firmly believe that Apple would want to avoid a spilt personality at all costs - even taking bad press because I believe a unified user experience in a particular OS (iOS and OS X have distinct user personalities but share common broad general ways of doing things - i.e. Notifications in both, lack of touch in OS X and lack of mouse support in iOS, common look of dialog boxes and user interface in both) is paramount to Apple.
<<< snip>>>
Are you saying Apple won't do things on the iPad they don't/won't do on the iPhone?
It's already been going on... there's a raft of programs that run on the iPad that would be impracticably ran on a 4" iPhone. Since the iPad has enough real estate to do a split screen with two programs running side-by-side, I can't see Apple not doing it at some point just because it's not practicable on a soon-to-be out-dated iPhone or iPod Touch. What's important from a UI standpoint is that both devices do what you intuitive expect them to do, in a way you'd expect to do it.
RAM is highly different from mass storage memory, just to keep that clear. However, when any brand X phone says they have 2 Gb of RAM, that is 32-bit RAM. Only Apple currently uses 64-bit RAM. Those longer words require the same number of transistors in operation as if the iPhone were to be running on 2 Gb of (32-bit) RAM. Roughly the same energy draw, and real estate as a brand X phone.
A lot of factors will affect battery draw, even the number of ports on the device has a small effect. By adding a barometer Apple has affected the draw. Apple uses a very dense SoC and does not suffer from thermal throttling when taxed to full specs of CPU and GPU performance - an iPhone will run full speed until the battery runs dry. Android phones with the 2 Gb of Rah Rah and high clock speeds can only go all out for minutes before needing to throttle back due to thermal constraints. Now, of course, at a mild loping speed (due to thermal constraints) the battery can last a shit-ton longer.
Regarding iPads; the larger physical size may allow enough thermal sink to handle more RAM in the SoC. Apple has used the iPad in the past to "field test" a higher performance SoC... they always could do that again.
Like you, I feel Apple is more conservative with their leading design than I'd wish they were... However, if Apple were to over reach their design and put out a bad product, it may never be forgotten by the unforgiving press, pundits and purchasers.
Corrected the spelling of a couple words.
The memory used in the iphone 5s and 6 is 1GB LPDDR3 RAM, there is absolutely nothing special about it. What is special is that the A8 can address that memory using a 64-bit wide memory interface...
Are you suggesting that the "1GB LPDDR3 RAM" chip was only being half used (in the iPhone 5) before Apple decided to use the whole chip when they went to 64 bits (in the 5c and 6 iPhones)? If it was being fully used as a 32-bit 1 GB chip, then where did Apple scrape up the transistors to form the extra registers? A chip is not magically 1 GB one day and suddenly a 1 GB the next day with twice the word length...
Keep in mind I've been talking all along about the transition from the iPhone 5, running 32-bit words, and the change to 64-bit words in the 5s and 6...
Are you saying Apple won't do things on the iPad they don't/won't do on the iPhone?
It's already been going on... there's a raft of programs that run on the iPad that would be impracticably ran on a 4" iPhone. Since the iPad has enough real estate to do a split screen with two programs running side-by-side, I can't see Apple not doing it at some point just because it's not practicable on a soon-to-be out-dated iPhone or iPod Touch. What's important from a UI standpoint is that both devices do what you intuitive expect them to do, in a way you'd expect to do it.
I am trying to say that Apple will take a deep hard look to make sure it is the right thing to do each time for each new function.
Look at cut and paste - IFC it took two versions of iOS before it appeared. Look at the 2X function when the screen size increased so legacy applications could run virtually unmodified while developer re-compiled their apps for the larger screen size.
I firmly believe that Apple will implement something to make it easy and an incentive for appearance/performance/etc, for developers to take advantage of the new function - perhaps a limited "split-screen" in landscape mode on the iPhone and landscape/portrait on the iPad - while allowing legacy apps to run virtually unmodified.
I do not see Apple just "sticking" something on a particular device without careful consideration - i.e. is this the right way to do it, is this something that we want to do, etc. - something about "skating to where the puck will be ..."
Unfortunately I do not have any reference material in regards to battery life between 1GB system RAM and 2GB system RAM (as no iPhone I am aware of has that amount) on an iPhone.
I think that using reference material for other OS will not allow us to draw the proper conclusions since they use a different model of how the OS handles everything.
Perhaps both of us can look to see if there is some reference material in regards to battery life between 512MB system RAM (IFC iPhone 5 used that amount) and 1GB system RAM (IRC iPhone 5s used/uses that amount) on an iPhone. That should provide solid material on which to draw an informed theory since it is same OS and similar hardware.
If we find that reference material then we could probably discard the changes implemented between versions greater than iOS 7 and stipulate that there are the same so we do not get distracted in the minute details - I think a broad theory works ...
It has always been my belief that Apple chose 1GB system RAM for several reasons (I cannot provide documentation since I could not find any and I am not privy to the design/cost/delivery/sales considerations that go into an iPhone launch) is that they looked at all system RAM configurations/types and decided that the best value to Apple and its customers was to chose an amount that they knew had the quality, quantity, stock inventory, and ability to be produced quickly at set quality and price for an huge number (200M if the analysts are correct - even 150M) over at least four quarters and that turned out to be 1GB system RAM.
Sounds good, let's do it. I know why Apple started out with 1GB and it made real sense at the time but right now I'm looking for a little more growth from Apple. As I stated before I'm actually okay with the iPhone having 1GB as it's just a phone, that and I don't use one. I actually fairly recently just started using the iPad, probably about a year now. It took a long time for me to get used to the idea of using such a limited OS but I finally pulled the trigger because as an armature musician I couldn't ignore all of the those great music apps and I absolutely love them now but I always knew sooner than later I would hit a roadblock with iOS's multitasking capabilities. I've read all the reasons why Apple has done what they did and have been called out on many occasions on here for wanting more then what is currently possible. Now more than ever though I want to start using my iPad a whole lot more but there is nothing more disconcerting than having a beat track going only to have it stop when I change over to an app for the synthesizer, only to have that stop when I start the recording app for my violin. I know there are apps that combine a lot of the things together but I don't want to use them, I've chosen my tool set and I don't really think I should have to choose anyway, especially when this can be easily rectified by allowing more than one app to be ran at the same time and of course more RAM. A lot of the apps I'm using are basally virtual versions of hardware so if the next iPad follows in the footsteps of the iPhone I will probably just get the hardware versions of the electric instruments I like and then use my Surface Pro 3 a whole lot more. Which is fine as using Abelton live and FL Studio Groove are absolutely sublime on it, so much so that I will probably hold off on buying a new MacBook until Apple adds a touchscreen, maybe even a screen that folds back, basically a Lenovo Yoga, hey I can dream can't eye. I've installed OSX on my Lenovo X230 so when I get back from the hospital I'm going to see how Logic performs on it. I will still of course use my iPad for recording as it's too cool for school and just one musical instrument app at a time as I've already invested a small mint in docks and midi controllers for it. Specially my MackieDL Mixer and Alesis Midi Docks.
Though I do have to say, I don't really need a computer anymore to do my music. My husband and kids got me a Teenage Engineering OP1 Portable Synthesizer so I could still make music while in the hospital and there is nothing that this little guy can't do. If any of you are into music and have an extra 800 bucks lying around, yeah I know, run, don't walk to your nearest music store to get what has to be the coolest musical gadget since the invention of midi itself, words cannot describe to you just how great this thing is.
Sounds good, let's do it. I know why Apple started out with 1GB and it made real sense at the time but right now I'm looking for a little more growth from Apple. As I stated before I'm actually okay with the iPhone having 1GB as it's just a phone, that and I don't use one. I actually fairly recently just started using the iPad, probably about a year now. It took a long time for me to get used to the idea of using such a limited OS but I finally pulled the trigger because as an armature musician I couldn't ignore all of the those great music apps and I absolutely love them now but I always knew sooner than later I would hit a roadblock with iOS's multitasking capabilities. I've read all the reasons why Apple has done what they did and have been called out on many occasions on here for wanting more then what is currently possible. Now more than ever though I want to start using my iPad a whole lot more but there is nothing more disconcerting than having a beat track going only to have it stop when I change over to an app for the synthesizer, only to have that stop when I start the recording app for my violin. I know there are apps that combine a lot of the things together but I don't want to use them, I've chosen my tool set and I don't really think I should have to choose anyway, especially when this can be easily rectified by allowing more than one app to be ran at the same time and of course more RAM. A lot of the apps I'm using are basally virtual versions of hardware so if the next iPad follows in the footsteps of the iPhone I will probably just get the hardware versions of the electric instruments I like and then use my Surface Pro 3 a whole lot more. Which is fine as using Abelton live and FL Studio Groove are absolutely sublime on it, so much so that I will probably hold off on buying a new MacBook until Apple adds a touchscreen, maybe even a screen that folds back, basically a Lenovo Yoga, hey I can dream can't eye. I've installed OSX on my Lenovo X230 so when I get back from the hospital I'm going to see how Logic performs on it. I will still of course use my iPad for recording as it's too cool for school and just one musical instrument app at a time as I've already invested a small mint in docks and midi controllers for it. Specially my MackieDL Mixer and Alesis Midi Docks.
Though I do have to say, I don't really need a computer anymore to do my music. My husband and kids got me a Teenage Engineering OP1 Portable Synthesizer so I could still make music while in the hospital and there is nothing that this little guy can't do. If any of you are into music and have an extra 800 bucks lying around, yeah I know, run, don't walk to your nearest music store to get what has to be the coolest musical gadget since the invention of midi itself, words cannot describe to you just how great this thing is.
Ok - I will start looking for any reference material.
I think some of the frustration individuals have is that with commodity hardware - i.e. RAM, NAND - Apple tends to not be at the bleeding/leading edge. In addition to that it appears that Apple wants to control all aspects of the hardware and software - almost to the point of obsession.
Bleeding edge/leading edge commodity hardware is generally very expensive, available in limited quantities, has a poor yield rate, unknown reliability issues.
And there are only so many manufacturers of commodity hardware and those manufacturers cater to other companies besides Apple and can only produce so many parts. Those manufacturers also have a vested interest in controlling availability - i.e. able to drive up unit cost
Unless someone is going to buy up all production time the manufacturer for leading/bleeding edge hardware is going to set the schedule on when something is produced and how much - i.e. Apple cannot control.
However, as a commodity hardware moves from bleeding/leading edge to used everywhere there are more manufacturers leading to more part availability, competition on unit pricing, etc - something Apple can control through per unit pricing, buying up of stocks, etc.
SoC are a different animal since they are NOT commodity hardware - each is a custom design. Apple can partner with a foundry to manufacture - again Apple controls not the other way around. There is more opportunity since a foundry does not want its production line to be idle - again opportunity for Apple to control not the other way around. Finally there is no pressure to sell to as many clients as possible since an SoC is not commodity hardware.
After a little more research it seems that there is a negligible baseline increase in power consumption to keep data addresses alive, the biggest consumers of power relevant to memory are the IMCs on the CPU, which do not draw more power from increased memory capacity.
Ok - I will start looking for any reference material.
I think some of the frustration individuals have is that with commodity hardware - i.e. RAM, NAND - Apple tends to not be at the bleeding/leading edge. In addition to that it appears that Apple wants to control all aspects of the hardware and software - almost to the point of obsession.
Bleeding edge/leading edge commodity hardware is generally very expensive, available in limited quantities, has a poor yield rate, unknown reliability issues.
And there are only so many manufacturers of commodity hardware and those manufacturers cater to other companies besides Apple and can only produce so many parts. Those manufacturers also have a vested interest in controlling availability - i.e. able to drive up unit cost
Unless someone is going to buy up all production time the manufacturer for leading/bleeding edge hardware is going to set the schedule on when something is produced and how much - i.e. Apple cannot control.
However, as a commodity hardware moves from bleeding/leading edge to used everywhere there are more manufacturers leading to more part availability, competition on unit pricing, etc - something Apple can control through per unit pricing, buying up of stocks, etc.
SoC are a different animal since they are NOT commodity hardware - each is a custom design. Apple can partner with a foundry to manufacture - again Apple controls not the other way around. There is more opportunity since a foundry does not want its production line to be idle - again opportunity for Apple to control not the other way around. Finally there is no pressure to sell to as many clients as possible since an SoC is not commodity hardware.
Adding clarity - the paragraph should read:
And there are only so many manufacturers of bleeding/leading commodity hardware and those manufacturers cater to other companies besides Apple and can only produce so many parts. Those manufacturers also have a vested interest in controlling availability - i.e. able to drive up unit cost
And there are only so many manufacturers of bleeding/leading commodity hardware and those manufacturers cater to other companies besides Apple and can only produce so many parts. Those manufacturers also have a vested interest in controlling availability - i.e. able to drive up unit cost
I haven't heard of a memory crisis, I still think it has to do with costs and maintaining a certain margin. The new iPhone 6 obvious costs more to make so once the prices for the components normalize we should see a 2GB in next years iPhone 6s. A good reason to wait as far as I'm concerned.
Unapparently Sony took up the quota for the year when they put 3GB of RAM in the Xperia Z2.
When Android L arrives, users can sell 1GB of theirs to Apple users.
Comments
To clear this up, let me explain how DRAM works. Most people should know this, but apparently the lesson has been forgotten.
Dynamic RAM needs to be refreshed every few milliseconds. That uses power. It's not like NAND used for storage. Even if there is nothing in DRAM, it still needs to be refreshed. DRAM can need heatsinks because it can get hot, in high performance modules. This uses power. Where does power come from in mobile devices? Yes, batteries. How much power gets used depends on how much RAM there is, and what kind of RAM. It doesn't use a huge amount of power at once, but it's always drawing power.
That article is decent, but woefully incomplete.
I know how DRAM works, I just don't by that 1GB more would have put such a large dent in battery life that Apple had no choice but to omit it. Memory is not one of the major battery draining components in a smart phone, regardless if it is always drawing power.The articles pertaining to what the major factors are to power consumption in a smart phone, like every other I have read doesn't discuss memory because of how little impact it actually has on the overall power scheme.
I have not seen any response on pricing, availability, yields, quantities in stock available, etc. between a 1GB module and a 2GB module.
It seems that everyone, including you, is not taking into consideration that a 2GB module might be significantly higher in cost, not available in the quantities that Apple needs, the production yields are very low thereby restricting the number of iPhone 6 units that can be built, there were small quantities available in stock, etc. and would not have allowed Apple to ship the number of units that Apple anticipated it would need for the launch of the iPhone 6.
If that is the case and Apple was to use a 2GB module and iPhone 6 was delayed or shipped in small quantities - what would your response be? Apple should have waited to get it right - Apple is waiting too long to release a new phone, Apple does not know what it is doing ...
It seems that you are not open to the possibility that there may have been a issue with procuring 2GB modules for the amount of iPhone 6 units that Apple anticipated it needs at launch and as such Apple did not use a 2GB module.
Actually my whole point in the beginning was that Apple didn't use 2GB because of costs, no, I'm fighting the whole idea that 2GB draws too much power, maybe once you start getting above 4GB but not 2GB. I haven't seen any literature or articles to suggest that it does, it would be a major design flaw if it was true as it would mean we would never see more than 1GB or face a thicker iPhone because the battery would have to be larger. I have read pretty much everything I can get my hands on pertaining to the A7 and A8 CPU, nothing about memory being a battery killer that people are suggesting here. Am I missing something, do you have a piece of technical literature that I can reference here to set me straight?
It doesn't need to put a large dent into battery life. All design is a tradeoff. This would be just one thing in many affecting battery life, and as such, was likely considered. When I designed equipment, memory draw was always a consideration. Whether or not you want to believe it, it was very likely a consideration for Apple as well.
Now more apps can run more tasks, different tasks.
I do not believe that iOS apps can run more tasks without restrictions (which is how I read your comment - i.e. the developer just decide what runs in the background regardless of the task) - rather that Apple has increased the number of allowed background tasks and how to use them rather specifically.
If that is what you meant - please excuse the following ... but it may be of interest.
Apple’s Guidance on What/How to Efficiently Run Your App In The Background
When you find it necessary to keep your app running in the background, iOS helps you do so efficiently and without draining system resources or the user’s battery. The techniques offered by iOS fall into three categories:
Apps that start a short task in the foreground can ask for time to finish that task when the app moves to the background.
Apps that initiate downloads in the foreground can hand off management of those downloads to the system, thereby allowing the app to be suspended or terminated while the download continues.
Apps that need to run in the background to support specific types of tasks can declare their support for one or more background execution modes.
List of Long-Running Tasks
In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background, such as a music player app Apps that record audio content while in the background
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Apps that need to download and process new content regularly Apps that receive regular updates from external accessories
From the Apple iPhone App Programing Guide - content property of Apple Inc. Copyright © 2014 Apple Inc. All rights reserved.
Another (to what is me) Clear Overview/Explanation of how iOS implements/allows for background tasks
A Change To Background Execution
There is a fundamental change in the way that iOS now handles background execution. Instead of allowing background tasks to start and run to completion or simply get terminated by iOS, execution will occur in bursts.
The idea behind this is to preserve battery life. When the user either backgrounds an app or locks their screen, they may or may not have additional time to run their background task. Also, the schedule that will be used to perform the background fetches is mostly determined by iOS. iOS will keep task execution at a minimum while the device is locked and tasks will be woken up and allowed to execute in groups. For example, when Mail is ready to check for e-mail or when a notification arrives, iOS will wake up other processes to run for a particular amount of time, then the processes will go quiet again.
Using this scheme, iOS is able to provide better battery life since the device will be quiet for certain periods of time and then handle multiple tasks during each wake up period. This is in contrast to the model for iOS 6 where apps will allowed to run background tasks, even after the user locked their device, and other processes would run given their independent polling cycle without coordination.
Background Fetching
The first new API change we'll cover is the background fetch. For this feature, iOS will monitor how the user uses your app and will periodically "wake up" your app in order to perform a fetch. This is an opportunity for your app to retrieve information from a remote service to be used in your app and displayed to the user. This keeps your app data fresh and reduces the amount of time it takes for the user to be able to interact with it.
One important detail to keep in mind is that you as a developer don't have much control as to when iOS will call upon your app to fetch the data. You can set the minimum interval time, but that is all. This minimal interval time tells iOS how frequently it makes sense to perform the fetch. You must set this value since it will default to UIApplicationBackgroundFetchInternalNone, which tells iOS to never perform a background fetch.
In most circumstances, you will want to set this value to be the minimum, which tells iOS to uses its best judgment as to when to perform the update based on how the user uses the app. In your app, set this value in the application:didFinishLaunchingWithOptions: method in your AppDelegate class.
Web content property of CapTech Ventures, Inc • 7100 Forest Avenue, 2nd Floor • Richmond, VA 23226 • 804.355.0511 © 2014 CapTech Ventures, Inc. All Rights Reserved.
Now trying to cover the above and the comments about system RAM quantity …
Admittedly this is only a small sample of documentation but I see a common thread here - write your App to preserve battery life and suspend your App so it does not take up processor cycles and/or memory space.
Using the above “common thread” where does it say that Apple choses what to put in an iPhone based on price?
My belief is that they did not need 2GB system RAM for a good general user (the percentage of which is always larger than Pro users) experience - specifically battery life and Apple was able to secure a set price and steady supply of quality 1GB system RAM modules, and a huge number in stock (so they do not run out in the middle of supplying their customers - again 4M is not a huge number). A huge number would be at least 30M - you need to have some for the production lines, account for those in transit, those in inventory, those waiting to be produced.
I suspect that the 2GB system RAM module was either constrained in quantity (lower quantity generally means higher price) or quality (if you need to have an iPhone returned because the RAM has failed - that is not a good thing for a good general user and critical for a Pro user).
I do not believe that iOS apps can run more tasks without restrictions (which is how I read your comment - i.e. the developer just decide what runs in the background regardless of the task) - rather that Apple has increased the number of allowed background tasks and how to use them rather specifically.
If that is what you meant - please excuse the following ... but it may be of interest.
Apple’s Guidance on What/How to Efficiently Run Your App In The Background
When you find it necessary to keep your app running in the background, iOS helps you do so efficiently and without draining system resources or the user’s battery. The techniques offered by iOS fall into three categories:
Apps that start a short task in the foreground can ask for time to finish that task when the app moves to the background.
Apps that initiate downloads in the foreground can hand off management of those downloads to the system, thereby allowing the app to be suspended or terminated while the download continues.
Apps that need to run in the background to support specific types of tasks can declare their support for one or more background execution modes.
List of Long-Running Tasks
In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background, such as a music player app Apps that record audio content while in the background
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Apps that need to download and process new content regularly Apps that receive regular updates from external accessories
From the Apple iPhone App Programing Guide - content property of Apple Inc. Copyright © 2014 Apple Inc. All rights reserved.
Another (to what is me) Clear Overview/Explanation of how iOS implements/allows for background tasks
A Change To Background Execution
There is a fundamental change in the way that iOS now handles background execution. Instead of allowing background tasks to start and run to completion or simply get terminated by iOS, execution will occur in bursts.
The idea behind this is to preserve battery life. When the user either backgrounds an app or locks their screen, they may or may not have additional time to run their background task. Also, the schedule that will be used to perform the background fetches is mostly determined by iOS. iOS will keep task execution at a minimum while the device is locked and tasks will be woken up and allowed to execute in groups. For example, when Mail is ready to check for e-mail or when a notification arrives, iOS will wake up other processes to run for a particular amount of time, then the processes will go quiet again.
Using this scheme, iOS is able to provide better battery life since the device will be quiet for certain periods of time and then handle multiple tasks during each wake up period. This is in contrast to the model for iOS 6 where apps will allowed to run background tasks, even after the user locked their device, and other processes would run given their independent polling cycle without coordination.
Background Fetching
The first new API change we'll cover is the background fetch. For this feature, iOS will monitor how the user uses your app and will periodically "wake up" your app in order to perform a fetch. This is an opportunity for your app to retrieve information from a remote service to be used in your app and displayed to the user. This keeps your app data fresh and reduces the amount of time it takes for the user to be able to interact with it.
One important detail to keep in mind is that you as a developer don't have much control as to when iOS will call upon your app to fetch the data. You can set the minimum interval time, but that is all. This minimal interval time tells iOS how frequently it makes sense to perform the fetch. You must set this value since it will default to UIApplicationBackgroundFetchInternalNone, which tells iOS to never perform a background fetch.
In most circumstances, you will want to set this value to be the minimum, which tells iOS to uses its best judgment as to when to perform the update based on how the user uses the app. In your app, set this value in the application:didFinishLaunchingWithOptions: method in your AppDelegate class.
Web content property of CapTech Ventures, Inc • 7100 Forest Avenue, 2nd Floor • Richmond, VA 23226 • 804.355.0511 © 2014 CapTech Ventures, Inc. All Rights Reserved.
Now trying to cover the above and the comments about system RAM quantity …
Admittedly this is only a small sample of documentation but I see a common thread here - write your App to preserve battery life and suspend your App so it does not take up processor cycles and/or memory space.
Using the above “common thread” where does it say that Apple choses what to put in an iPhone based on price?
My belief is that they did not need 2GB system RAM for a good general user (the percentage of which is always larger than Pro users) experience - specifically battery life and Apple was able to secure a set price and steady supply of quality 1GB system RAM modules, and a huge number in stock (so they do not run out in the middle of supplying their customers - again 4M is not a huge number). A huge number would be at least 30M - you need to have some for the production lines, account for those in transit, those in inventory, those waiting to be produced.
I suspect that the 2GB system RAM module was either constrained in quantity (lower quantity generally means higher price) or quality (if you need to have an iPhone returned because the RAM has failed - that is not a good thing for a good general user and critical for a Pro user).
A huge number in stock and/or able to be produced quickly at the set price and quality becomes EVEN MORE important (if the analysts predictions are correct) when you are going to sell 200M in 90 days.
It doesn't need to put a large dent into battery life. All design is a tradeoff. This would be just one thing in many affecting battery life, and as such, was likely considered. When I designed equipment, memory draw was always a consideration. Whether or not you want to believe it, it was very likely a consideration for Apple as well.
I'm sure it was a consideration, everything is when you are designing a new gadget, that's just logical, the real question is though and I have yet to see any real answer yet, except for guessing, does 2GB of RAM draw too much power from the battery and I honestly don't think so. Memory power consumption has never been an issue before nor was it even given as an excuse when Apple didn't use 2GB in the iPhone 5, 5c, 5s, iPad Air or iPad Air Mini. I would have rather Apple stayed with the A7 and upped the RAM to 2GB if it was, the A7 is still more than capable. But I don't think it's an issue and will continue being thick headed about it until I see any real proof to contrary. I think it was about pricing, maybe even supply constraints, again, I just hope the new iPad Air will have 2GB.
I do not believe that iOS apps can run more tasks without restrictions (which is how I read your comment - i.e. the developer just decide what runs in the background regardless of the task) - rather that Apple has increased the number of allowed background tasks and how to use them rather specifically.
If that is what you meant - please excuse the following ... but it may be of interest.
Apple’s Guidance on What/How to Efficiently Run Your App In The Background
When you find it necessary to keep your app running in the background, iOS helps you do so efficiently and without draining system resources or the user’s battery. The techniques offered by iOS fall into three categories:
Apps that start a short task in the foreground can ask for time to finish that task when the app moves to the background.
Apps that initiate downloads in the foreground can hand off management of those downloads to the system, thereby allowing the app to be suspended or terminated while the download continues.
Apps that need to run in the background to support specific types of tasks can declare their support for one or more background execution modes.
List of Long-Running Tasks
In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background, such as a music player app Apps that record audio content while in the background
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Apps that need to download and process new content regularly Apps that receive regular updates from external accessories
From the Apple iPhone App Programing Guide - content property of Apple Inc. Copyright © 2014 Apple Inc. All rights reserved.
Another (to what is me) Clear Overview/Explanation of how iOS implements/allows for background tasks
A Change To Background Execution
There is a fundamental change in the way that iOS now handles background execution. Instead of allowing background tasks to start and run to completion or simply get terminated by iOS, execution will occur in bursts.
The idea behind this is to preserve battery life. When the user either backgrounds an app or locks their screen, they may or may not have additional time to run their background task. Also, the schedule that will be used to perform the background fetches is mostly determined by iOS. iOS will keep task execution at a minimum while the device is locked and tasks will be woken up and allowed to execute in groups. For example, when Mail is ready to check for e-mail or when a notification arrives, iOS will wake up other processes to run for a particular amount of time, then the processes will go quiet again.
Using this scheme, iOS is able to provide better battery life since the device will be quiet for certain periods of time and then handle multiple tasks during each wake up period. This is in contrast to the model for iOS 6 where apps will allowed to run background tasks, even after the user locked their device, and other processes would run given their independent polling cycle without coordination.
Background Fetching
The first new API change we'll cover is the background fetch. For this feature, iOS will monitor how the user uses your app and will periodically "wake up" your app in order to perform a fetch. This is an opportunity for your app to retrieve information from a remote service to be used in your app and displayed to the user. This keeps your app data fresh and reduces the amount of time it takes for the user to be able to interact with it.
One important detail to keep in mind is that you as a developer don't have much control as to when iOS will call upon your app to fetch the data. You can set the minimum interval time, but that is all. This minimal interval time tells iOS how frequently it makes sense to perform the fetch. You must set this value since it will default to UIApplicationBackgroundFetchInternalNone, which tells iOS to never perform a background fetch.
In most circumstances, you will want to set this value to be the minimum, which tells iOS to uses its best judgment as to when to perform the update based on how the user uses the app. In your app, set this value in the application:didFinishLaunchingWithOptions: method in your AppDelegate class.
Web content property of CapTech Ventures, Inc • 7100 Forest Avenue, 2nd Floor • Richmond, VA 23226 • 804.355.0511 © 2014 CapTech Ventures, Inc. All Rights Reserved.
Now trying to cover the above and the comments about system RAM quantity …
Admittedly this is only a small sample of documentation but I see a common thread here - write your App to preserve battery life and suspend your App so it does not take up processor cycles and/or memory space.
Using the above “common thread” where does it say that Apple choses what to put in an iPhone based on price?
My belief is that they did not need 2GB system RAM for a good general user (the percentage of which is always larger than Pro users) experience - specifically battery life and Apple was able to secure a set price and steady supply of quality 1GB system RAM modules, and a huge number in stock (so they do not run out in the middle of supplying their customers - again 4M is not a huge number). A huge number would be at least 30M - you need to have some for the production lines, account for those in transit, those in inventory, those waiting to be produced.
I suspect that the 2GB system RAM module was either constrained in quantity (lower quantity generally means higher price) or quality (if you need to have an iPhone returned because the RAM has failed - that is not a good thing for a good general user and critical for a Pro user).
Really nice writeup, thank you, I would love to see an override feature for when the iPad is plugged in to allow more to be ran in the background. The iPad is so close to being a really great tool for me, I just need those restrictions lifted so I can run just a few music production apps at once, oh and more memory of course. If not, will have to buy another iPad, maybe 2 more or start using my Surface 3 a lot more.
That of course is your prerogative, but I just can't believe that Apple's engineers were unable to come up with an elegant solution to accommodate 2GB of memory because of power drain. That would suggest bad design, inadequate battery size, heck even a lack of knowledge on the matter and there is no way Apple is incompetent, what, that's really what you're suggesting here. Antagonist, "Oh man, not again, Apple couldn't figure out how to install 2GB of memory in their new iPhone this time around either, oh well, maybe next year". Anyway, would love to see any technical literature stating that having 2GB of RAM in your phone would cause anything but a negligible amount of power loss. As it just doesn't seem like a valid excuse to me, especially when I have phones with 2GB of memory that seem to be unaffected in any real manner because of it. In fact in every single article I've read in the last three days, which has now surpassed 30, about what affects battery life in a modern smartphone, not a single one mentioned that memory was a big factor, heck none even mentioned memory. Yes of course everything with a current in the phone will cause the battery to drain but memory size is not a major factor. I honest don't care about the iPhone but I was greatly anticipating that the iPad would have 2GB of memory, unfortunately the new iPhone took away a lot of that hope.
I'm going to start posting every good article I can find about battery usage here;
1.)
http://electronicdesign.com/ed-europe/what-drains-smart-phone-battery
2.)
To clear this up, let me explain how DRAM works. Most people should know this, but apparently the lesson has been forgotten.
Dynamic RAM needs to be refreshed every few milliseconds. That uses power. It's not like NAND used for storage. Even if there is nothing in DRAM, it still needs to be refreshed. DRAM can need heatsinks because it can get hot, in high performance modules. This uses power. Where does power come from in mobile devices? Yes, batteries. How much power gets used depends on how much RAM there is, and what kind of RAM. It doesn't use a huge amount of power at once, but it's always drawing power.
That article is decent, but woefully incomplete.
I read the article too and it is inadequate. The writer had his/her eye set on gross power consumption points and was totally oblivious to all the smaller places where power is used.
Actually my whole point in the beginning was that Apple didn't use 2GB because of costs, no, I'm fighting the whole idea that 2GB draws too much power, maybe once you start getting above 4GB but not 2GB. I haven't seen any literature or articles to suggest that it does, it would be a major design flaw if it was true as it would mean we would never see more than 1GB or face a thicker iPhone because the battery would have to be larger. I have read pretty much everything I can get my hands on pertaining to the A7 and A8 CPU, nothing about memory being a battery killer that people are suggesting here. Am I missing something, do you have a piece of technical literature that I can reference here to set me straight?
Unfortunately I do not have any reference material in regards to battery life between 1GB system RAM and 2GB system RAM (as no iPhone I am aware of has that amount) on an iPhone.
I think that using reference material for other OS will not allow us to draw the proper conclusions since they use a different model of how the OS handles everything.
Perhaps both of us can look to see if there is some reference material in regards to battery life between 512MB system RAM (IFC iPhone 5 used that amount) and 1GB system RAM (IRC iPhone 5s used/uses that amount) on an iPhone. That should provide solid material on which to draw an informed theory since it is same OS and similar hardware.
If we find that reference material then we could probably discard the changes implemented between versions greater than iOS 7 and stipulate that there are the same so we do not get distracted in the minute details - I think a broad theory works ...
It has always been my belief that Apple chose 1GB system RAM for several reasons (I cannot provide documentation since I could not find any and I am not privy to the design/cost/delivery/sales considerations that go into an iPhone launch) is that they looked at all system RAM configurations/types and decided that the best value to Apple and its customers was to chose an amount that they knew had the quality, quantity, stock inventory, and ability to be produced quickly at set quality and price for an huge number (200M if the analysts are correct - even 150M) over at least four quarters and that turned out to be 1GB system RAM.
Really nice writeup, thank you, I would love to see an override feature for when the iPad is plugged in to allow more to be ran in the background. The iPad is so close to being a really great tool for me, I just need those restrictions lifted so I can run just a few music production apps at once, oh and more memory of course. If not, will have to buy another iPad, maybe 2 more or start using my Surface 3 a lot more.
While that would be great for iPad users it would start a split in user experience (spilt personality) for iOS devices. Oh the iPhone does not do that but the iPad does ... that could quickly lead to confusion, frustration, etc. for the general user.
I firmly believe that Apple would want to avoid a spilt personality at all costs - even taking bad press because I believe a unified user experience in a particular OS (iOS and OS X have distinct user personalities but share common broad general ways of doing things - i.e. Notifications in both, lack of touch in OS X and lack of mouse support in iOS, common look of dialog boxes and user interface in both) is paramount to Apple.
One can only look at Microsoft and Windows 8 to see what can happen when you allow "split personalities". Metro is completely different than the desktop interface and you can switch between them. How confusing is that?
I do not believe the general user would not understand much less accept that from Apple.
I believe a large number of general users appreciate that the interface and how things work are the same on the iPhone and iPad and that Apple did not expose the OS X interface on those devices which would lead to confusion and fear.
And yes I understand catering to the general user usually means it sucks for a Pro user - but I think we have to accept that this is the way it is for Apple.
Apple has avoided changing its culture just so that it can sell more devices in the Enterprise so I think we can safely run with that it is "the average consumer first, everyone else last" as the motivation for device/design/specification/user experience decisions at Apple.
And if Apple keeps following that motivation then the money will come in since each consumer can individually (versus the Enterprise) purchase/not purchase an Apple device. If general users do not buy enough then everyone at Apple does not get to come to work each day.
Here's a thought I haven't heard bantered about.
With the iPhone 5s, Apple moved from 1 Gb of 32-bit RAM to 1 Gb of 64-bit RAM. While THIS alone doubled the number of transistors to make up 1 Gb of memory. Perhaps Apple is doing some tricks to use both word sizes within RAM? Many things the GPU does won't require 64-bit addressing any way one looks at it. Furthermore, as more apps require 64-bit memory addressing, the ratio of shorter words in memory will lessen. By then Apple could move to a longer word CPU, increase the mixed word-length storage and complete one more transition to more powerful hardware without leaving anyone behind, except, of course, various Luddites who are proud of what they can accomplish with an original iPhone and a paper clip - when the humidity is especially high.
A GB is a GB regardless of the memory width, because that capital "B" stands for byte, which is 8 bits. All memory is called out in bytes. If it's Gb, with the lower case "b", then it stands for bit, which is one eights byte (eight bits in a byte). So you may read about a 128Gb chip, which is a 16GB chip.
If you read about a 32 bit memory path, or lane, that doesn't mean more memory, just how it's organized. The same thing is true of 64 bit memory path.
I'm not arguing about a Gb being a Gb. I'm saying a Gb with a 32-bit path has the half the transistors, flip flops, or mojo as a Gb chip with a 64-bit path. if you have a RAM chip with a certain memory capacity, then that capacity is based on the chip being used at a certain word size.
You cannot take a one-Gb chip and decide to have twice the word length without halving the word count. THAT'S my point.
For Apple to increase their word length to 64-bit, they needed to DO SOMETHING to the supplied memory if they also did not decrease the RAM size stated in NUMBER of memory words. Capisce??
Really nice writeup, thank you, I would love to see an override feature for when the iPad is plugged in to allow more to be ran in the background. The iPad is so close to being a really great tool for me, I just need those restrictions lifted so I can run just a few music production apps at once, oh and more memory of course. If not, will have to buy another iPad, maybe 2 more or start using my Surface 3 a lot more.
While that would be great for iPad users it would start a split in user experience (spilt personality) for iOS devices. Oh the iPhone does not do that but the iPad does ... that could quickly lead to confusion, frustration, etc. for the general user.
I firmly believe that Apple would want to avoid a spilt personality at all costs - even taking bad press because I believe a unified user experience in a particular OS (iOS and OS X have distinct user personalities but share common broad general ways of doing things - i.e. Notifications in both, lack of touch in OS X and lack of mouse support in iOS, common look of dialog boxes and user interface in both) is paramount to Apple.
<<< snip>>>Are you saying Apple won't do things on the iPad they don't/won't do on the iPhone?
It's already been going on... there's a raft of programs that run on the iPad that would be impracticably ran on a 4" iPhone. Since the iPad has enough real estate to do a split screen with two programs running side-by-side, I can't see Apple not doing it at some point just because it's not practicable on a soon-to-be out-dated iPhone or iPod Touch. What's important from a UI standpoint is that both devices do what you intuitive expect them to do, in a way you'd expect to do it.
RAM is highly different from mass storage memory, just to keep that clear. However, when any brand X phone says they have 2 Gb of RAM, that is 32-bit RAM. Only Apple currently uses 64-bit RAM. Those longer words require the same number of transistors in operation as if the iPhone were to be running on 2 Gb of (32-bit) RAM. Roughly the same energy draw, and real estate as a brand X phone.
A lot of factors will affect battery draw, even the number of ports on the device has a small effect. By adding a barometer Apple has affected the draw. Apple uses a very dense SoC and does not suffer from thermal throttling when taxed to full specs of CPU and GPU performance - an iPhone will run full speed until the battery runs dry. Android phones with the 2 Gb of Rah Rah and high clock speeds can only go all out for minutes before needing to throttle back due to thermal constraints. Now, of course, at a mild loping speed (due to thermal constraints) the battery can last a shit-ton longer.
Regarding iPads; the larger physical size may allow enough thermal sink to handle more RAM in the SoC. Apple has used the iPad in the past to "field test" a higher performance SoC... they always could do that again.
Like you, I feel Apple is more conservative with their leading design than I'd wish they were... However, if Apple were to over reach their design and put out a bad product, it may never be forgotten by the unforgiving press, pundits and purchasers.
Corrected the spelling of a couple words.
The memory used in the iphone 5s and 6 is 1GB LPDDR3 RAM, there is absolutely nothing special about it. What is special is that the A8 can address that memory using a 64-bit wide memory interface...
Are you suggesting that the "1GB LPDDR3 RAM" chip was only being half used (in the iPhone 5) before Apple decided to use the whole chip when they went to 64 bits (in the 5c and 6 iPhones)? If it was being fully used as a 32-bit 1 GB chip, then where did Apple scrape up the transistors to form the extra registers? A chip is not magically 1 GB one day and suddenly a 1 GB the next day with twice the word length...
Keep in mind I've been talking all along about the transition from the iPhone 5, running 32-bit words, and the change to 64-bit words in the 5s and 6...
Are you saying Apple won't do things on the iPad they don't/won't do on the iPhone?
It's already been going on... there's a raft of programs that run on the iPad that would be impracticably ran on a 4" iPhone. Since the iPad has enough real estate to do a split screen with two programs running side-by-side, I can't see Apple not doing it at some point just because it's not practicable on a soon-to-be out-dated iPhone or iPod Touch. What's important from a UI standpoint is that both devices do what you intuitive expect them to do, in a way you'd expect to do it.
I am trying to say that Apple will take a deep hard look to make sure it is the right thing to do each time for each new function.
Look at cut and paste - IFC it took two versions of iOS before it appeared. Look at the 2X function when the screen size increased so legacy applications could run virtually unmodified while developer re-compiled their apps for the larger screen size.
I firmly believe that Apple will implement something to make it easy and an incentive for appearance/performance/etc, for developers to take advantage of the new function - perhaps a limited "split-screen" in landscape mode on the iPhone and landscape/portrait on the iPad - while allowing legacy apps to run virtually unmodified.
I do not see Apple just "sticking" something on a particular device without careful consideration - i.e. is this the right way to do it, is this something that we want to do, etc. - something about "skating to where the puck will be ..."
Unfortunately I do not have any reference material in regards to battery life between 1GB system RAM and 2GB system RAM (as no iPhone I am aware of has that amount) on an iPhone.
I think that using reference material for other OS will not allow us to draw the proper conclusions since they use a different model of how the OS handles everything.
Perhaps both of us can look to see if there is some reference material in regards to battery life between 512MB system RAM (IFC iPhone 5 used that amount) and 1GB system RAM (IRC iPhone 5s used/uses that amount) on an iPhone. That should provide solid material on which to draw an informed theory since it is same OS and similar hardware.
If we find that reference material then we could probably discard the changes implemented between versions greater than iOS 7 and stipulate that there are the same so we do not get distracted in the minute details - I think a broad theory works ...
It has always been my belief that Apple chose 1GB system RAM for several reasons (I cannot provide documentation since I could not find any and I am not privy to the design/cost/delivery/sales considerations that go into an iPhone launch) is that they looked at all system RAM configurations/types and decided that the best value to Apple and its customers was to chose an amount that they knew had the quality, quantity, stock inventory, and ability to be produced quickly at set quality and price for an huge number (200M if the analysts are correct - even 150M) over at least four quarters and that turned out to be 1GB system RAM.
Sounds good, let's do it. I know why Apple started out with 1GB and it made real sense at the time but right now I'm looking for a little more growth from Apple. As I stated before I'm actually okay with the iPhone having 1GB as it's just a phone, that and I don't use one. I actually fairly recently just started using the iPad, probably about a year now. It took a long time for me to get used to the idea of using such a limited OS but I finally pulled the trigger because as an armature musician I couldn't ignore all of the those great music apps and I absolutely love them now but I always knew sooner than later I would hit a roadblock with iOS's multitasking capabilities. I've read all the reasons why Apple has done what they did and have been called out on many occasions on here for wanting more then what is currently possible. Now more than ever though I want to start using my iPad a whole lot more but there is nothing more disconcerting than having a beat track going only to have it stop when I change over to an app for the synthesizer, only to have that stop when I start the recording app for my violin. I know there are apps that combine a lot of the things together but I don't want to use them, I've chosen my tool set and I don't really think I should have to choose anyway, especially when this can be easily rectified by allowing more than one app to be ran at the same time and of course more RAM. A lot of the apps I'm using are basally virtual versions of hardware so if the next iPad follows in the footsteps of the iPhone I will probably just get the hardware versions of the electric instruments I like and then use my Surface Pro 3 a whole lot more. Which is fine as using Abelton live and FL Studio Groove are absolutely sublime on it, so much so that I will probably hold off on buying a new MacBook until Apple adds a touchscreen, maybe even a screen that folds back, basically a Lenovo Yoga, hey I can dream can't eye. I've installed OSX on my Lenovo X230 so when I get back from the hospital I'm going to see how Logic performs on it. I will still of course use my iPad for recording as it's too cool for school and just one musical instrument app at a time as I've already invested a small mint in docks and midi controllers for it. Specially my Mackie DL Mixer and Alesis Midi Docks.
Though I do have to say, I don't really need a computer anymore to do my music. My husband and kids got me a Teenage Engineering OP1 Portable Synthesizer so I could still make music while in the hospital and there is nothing that this little guy can't do. If any of you are into music and have an extra 800 bucks lying around, yeah I know, run, don't walk to your nearest music store to get what has to be the coolest musical gadget since the invention of midi itself, words cannot describe to you just how great this thing is.
Sounds good, let's do it. I know why Apple started out with 1GB and it made real sense at the time but right now I'm looking for a little more growth from Apple. As I stated before I'm actually okay with the iPhone having 1GB as it's just a phone, that and I don't use one. I actually fairly recently just started using the iPad, probably about a year now. It took a long time for me to get used to the idea of using such a limited OS but I finally pulled the trigger because as an armature musician I couldn't ignore all of the those great music apps and I absolutely love them now but I always knew sooner than later I would hit a roadblock with iOS's multitasking capabilities. I've read all the reasons why Apple has done what they did and have been called out on many occasions on here for wanting more then what is currently possible. Now more than ever though I want to start using my iPad a whole lot more but there is nothing more disconcerting than having a beat track going only to have it stop when I change over to an app for the synthesizer, only to have that stop when I start the recording app for my violin. I know there are apps that combine a lot of the things together but I don't want to use them, I've chosen my tool set and I don't really think I should have to choose anyway, especially when this can be easily rectified by allowing more than one app to be ran at the same time and of course more RAM. A lot of the apps I'm using are basally virtual versions of hardware so if the next iPad follows in the footsteps of the iPhone I will probably just get the hardware versions of the electric instruments I like and then use my Surface Pro 3 a whole lot more. Which is fine as using Abelton live and FL Studio Groove are absolutely sublime on it, so much so that I will probably hold off on buying a new MacBook until Apple adds a touchscreen, maybe even a screen that folds back, basically a Lenovo Yoga, hey I can dream can't eye. I've installed OSX on my Lenovo X230 so when I get back from the hospital I'm going to see how Logic performs on it. I will still of course use my iPad for recording as it's too cool for school and just one musical instrument app at a time as I've already invested a small mint in docks and midi controllers for it. Specially my Mackie DL Mixer and Alesis Midi Docks.
Though I do have to say, I don't really need a computer anymore to do my music. My husband and kids got me a Teenage Engineering OP1 Portable Synthesizer so I could still make music while in the hospital and there is nothing that this little guy can't do. If any of you are into music and have an extra 800 bucks lying around, yeah I know, run, don't walk to your nearest music store to get what has to be the coolest musical gadget since the invention of midi itself, words cannot describe to you just how great this thing is.
Ok - I will start looking for any reference material.
I think some of the frustration individuals have is that with commodity hardware - i.e. RAM, NAND - Apple tends to not be at the bleeding/leading edge. In addition to that it appears that Apple wants to control all aspects of the hardware and software - almost to the point of obsession.
Bleeding edge/leading edge commodity hardware is generally very expensive, available in limited quantities, has a poor yield rate, unknown reliability issues.
And there are only so many manufacturers of commodity hardware and those manufacturers cater to other companies besides Apple and can only produce so many parts. Those manufacturers also have a vested interest in controlling availability - i.e. able to drive up unit cost
Unless someone is going to buy up all production time the manufacturer for leading/bleeding edge hardware is going to set the schedule on when something is produced and how much - i.e. Apple cannot control.
However, as a commodity hardware moves from bleeding/leading edge to used everywhere there are more manufacturers leading to more part availability, competition on unit pricing, etc - something Apple can control through per unit pricing, buying up of stocks, etc.
SoC are a different animal since they are NOT commodity hardware - each is a custom design. Apple can partner with a foundry to manufacture - again Apple controls not the other way around. There is more opportunity since a foundry does not want its production line to be idle - again opportunity for Apple to control not the other way around. Finally there is no pressure to sell to as many clients as possible since an SoC is not commodity hardware.
Ok - I will start looking for any reference material.
I think some of the frustration individuals have is that with commodity hardware - i.e. RAM, NAND - Apple tends to not be at the bleeding/leading edge. In addition to that it appears that Apple wants to control all aspects of the hardware and software - almost to the point of obsession.
Bleeding edge/leading edge commodity hardware is generally very expensive, available in limited quantities, has a poor yield rate, unknown reliability issues.
And there are only so many manufacturers of commodity hardware and those manufacturers cater to other companies besides Apple and can only produce so many parts. Those manufacturers also have a vested interest in controlling availability - i.e. able to drive up unit cost
Unless someone is going to buy up all production time the manufacturer for leading/bleeding edge hardware is going to set the schedule on when something is produced and how much - i.e. Apple cannot control.
However, as a commodity hardware moves from bleeding/leading edge to used everywhere there are more manufacturers leading to more part availability, competition on unit pricing, etc - something Apple can control through per unit pricing, buying up of stocks, etc.
SoC are a different animal since they are NOT commodity hardware - each is a custom design. Apple can partner with a foundry to manufacture - again Apple controls not the other way around. There is more opportunity since a foundry does not want its production line to be idle - again opportunity for Apple to control not the other way around. Finally there is no pressure to sell to as many clients as possible since an SoC is not commodity hardware.
Adding clarity - the paragraph should read:
And there are only so many manufacturers of bleeding/leading commodity hardware and those manufacturers cater to other companies besides Apple and can only produce so many parts. Those manufacturers also have a vested interest in controlling availability - i.e. able to drive up unit cost
Adding clarity - the paragraph should read:
And there are only so many manufacturers of bleeding/leading commodity hardware and those manufacturers cater to other companies besides Apple and can only produce so many parts. Those manufacturers also have a vested interest in controlling availability - i.e. able to drive up unit cost
I haven't heard of a memory crisis, I still think it has to do with costs and maintaining a certain margin. The new iPhone 6 obvious costs more to make so once the prices for the components normalize we should see a 2GB in next years iPhone 6s. A good reason to wait as far as I'm concerned.
Unapparently Sony took up the quota for the year when they put 3GB of RAM in the Xperia Z2.
When Android L arrives, users can sell 1GB of theirs to Apple users.