Apple Seeds iOS 7.1 Beta 2 to Developers [Updated]

[Michael Goff]

It's because that site is crap. It tries and load a crap ton of videos on page load.

Just throwing this out there... doesn't crash my Surface RT doing the thing that crashes Safari on an iPad.

 

[enoC]

Nothing happen to me. And updated fine

Could it be because your iDevice is on a developer account?

 

[C DM]

Because it didn't happen to me in any of the iOS 7 betas, current release versions and beta 1. I remember a cool keyboard animation in the iOS 7 betas that was labeled a bug and changed in later betas.

Happened in betas and all final versions of iOS 7.0, so doesn't seem like it would be a bug in iOS 7.1.

----------

Not sure if this has been mentioned yet, but Notification Center now shows your next event rather than showing what's happening for the next six hours.

That along with the Calendar app improvements, it looks like Apple put in a fair amount of work in making calendaring better in iOS 7.1.

 

[iTom17]

Not sure if it has been mentioned already, but when you now enable Higher contrast (or whatever it's called in English; because I'm Dutch, haha) the Control Center has a darker color. Like it over the previous light grey one.

 

[Riemann Zeta]

What is with Apple's passive-aggressive use of the translucent dark keyboard? It is added then removed from every other iOS 7 beta and then always locked out for RTM releases, except, for some strange reason, when trying to use spotlight--then the keyboard is allowed to be translucent.

The iOS 7 interface shows promise, but it is highly inconsistent and not very clearly planned. It feels like Windows 8 in that respect--a hodgepodge of UI paradigms all thrown together, without a clear design philosophy.

 

[robertkarlsen]

My UDID is registered...i should be fine with B2?

 

[zed1291]

I don't really care if they have a "dark" option for the keyboard, I just want them to return the .com button. Why did they get rid of that. It's such a simple feature, but greatly missed when gone.

There are 12 pages of comments and likely I'm not the first to reply, but tap and hold the "." and the .com will appear.

----------

also, the dark keyboard option is gone but there is a new accessibility option called "Button Shapes".

Button shapes looks horrible.

I like the idea, not the implementation

 

[ari67]

It would be good if apple put an option like color profile in order to neutralize yellow tint in idevices by users in final vesion

 

[bbfc]

Nothing happen to me. And updated fine

Is your UDID registered?

 

[PNutts]

This option shows that Apple doesn't really want you to be using buttons. The option is just there for people that don't understand the interface elements.

No. Removing control elements so that there are no hints or guides doesn't mean someone doesn't "understand the interface elements". It means you have to read and study the screen to try to figure out how to interface with the UI.

Do you really want to tell me that people get confused because of the lack of buttons? Sure there are things that can be done better, but ios 7 lays the foundation for a new, refreshing design.

Yes. Buttons are why anyone can pick up an iOS 6 or less iDevice and use it. iOS 7 is a pain for us that know what we can do (and just need to figure out how). For someone new to iOS it's a baffling mystery.

There is a thread on forwarding iMessages now that the Edit button was removed. To me it's the best example of how usability is an afterthought in iOS 7.

 

[Menneisyys2]

Just throwing this out there... doesn't crash my Surface RT doing the thing that crashes Safari on an iPad.

iOS has an exceptionally memory-hungry HTML renderer widget. Even Opera Mini's (OK, far less capable, but for basic stuff, pretty OK) custom, non UIWebView-based HTML renderer is far better, memory usage-wise.

(I've made a lot of tests with Opera Mini back in the iPad 1 days. Even 40-50 independent tabs could be kept loaded in the memory. With iOS' UIWebView, not even 3...)

This is why iOS produces so bad results.

BTW, regarding nin.com: on the iPhone 5 7.0.4, if you start scrolling, UIWebView easily allocates 600+ Mbytes of RAM; hence the crashes. (I've just finished the iPhone 5 tests.) More definite figures later, after my having run the same tests on my other devices / configs.

 

[Michael Goff]

iOS has an exceptionally memory-hungry HTML renderer widget. Even Opera Mini's (OK, far less capable, but for basic stuff, pretty OK) custom, non UIWebView-based HTML renderer is far better, memory usage-wise.

(I've made a lot of tests with Opera Mini back in the iPad 1 days. Even 40-50 independent tabs could be kept loaded in the memory. With iOS' UIWebView, not even 3...)

This is why iOS produces so bad results.

BTW, regarding nin.com: on the iPhone 5 7.0.4, if you start scrolling, UIWebView easily allocates 600+ Mbytes of RAM; hence the crashes. (I've just finished the iPhone 5 tests.) More definite figures later, after my having run the same tests on my other devices / configs.

If they're going to make it so RAM hungry, why skimp on the RAM?

 

[Menneisyys2]

If they're going to make it so RAM hungry, why skimp on the RAM?

They think the majority of their customers (who aren't at all tecnhical) aren't bothered or won't fault Apple, and, therefore, they consider a saving of, say, $5...10 (additional RAM price) is justifiable? Or, is it just another kind of planned obsolescence (the rumored iPad Pro will surely have 2+ GB of RAM, particularly if it supports windowed multitasking as Samsung Android / Windows do)? Dunno. Nevertheless, they surely are aware of the UIWebView (incl. Safari) problem as it has been present since the very beginning, and has been made even worse by the introduction of Retina screens.

 

[sbailey4]

No. Removing control elements so that there are no hints or guides doesn't mean someone doesn't "understand the interface elements". It means you have to read and study the screen to try to figure out how to interface with the UI.



Yes. Buttons are why anyone can pick up an iOS 6 or less iDevice and use it. iOS 7 is a pain for us that know what we can do (and just need to figure out how). For someone new to iOS it's a baffling mystery.

There is a thread on forwarding iMessages now that the Edit button was removed. To me it's the best example of how usability is an afterthought in iOS 7.

Great example. Just like the "." instead of the .com that used to be in the keyboard. Have to use google to figure out how to do 1/2 the things that were blatantly obvious in previous versions. I have 80 yr old uncle who got iPhone about a year ago moving from old LG flip phone. Picked right up on how to make it do what he wanted. Now he calls me to ask, "before this new update I could xxxxx. Can I do that now? And how can I?" Hell 1/2 of what he asks me I have to go figure out myself. Like the examples above, the hidden "improved" way of doing it. How is that better? And a bouncing control panel slide, really!!?!? What functionality does that add other than helping to cycle your battery due to the extra cpu cycles needed to make that happen. "Lets hide useful items and add this bouncy control panel to compliment the pastel pink icons." Interesting thought process indeed.

 

[Michael Goff]

They think the majority of their customers (who aren't at all tecnhical) aren't bothered or won't fault Apple, and, therefore, they consider a saving of, say, $5...10 (additional RAM price) is justifiable? Or, is it just another kind of planned obsolescence (the rumored iPad Pro will surely have 2+ GB of RAM, particularly if it supports windowed multitasking as Samsung Android / Windows do)? Dunno. Nevertheless, they surely are aware of the UIWebView (incl. Safari) problem as it has been present since the very beginning, and has been made even worse by the introduction of Retina screens.

And then the 2gb iPad comes out in time for them to add enough features to where people still get quite a few "low memory" warnings. Either way, they really need to do something about UIWebView taking up so much RAM.

 

[Menneisyys2]

Either way, they really need to do something about UIWebView taking up so much RAM.

I don't think they will - at least in the near future. This, as I've pointed out above, has always been one of the Achilles' heel of iOS. They have been aware of it at least since 2008 - particularly since 2010, when the iPad 1 and the iPhone 4 was introduced with vastly higher UIWebView memory requirements (because of the higher-res screens). They would have surely acted if they had wanted to in these years.

 

[noez92]

maybe they would think about implementing 3G, 3G / 2G or 2G toggle to next release?

 

[bbfc]

maybe they would think about implementing 3G, 3G / 2G or 2G toggle to next release?

Why on earth would they implement a 2G toggle??

 

[Menneisyys2]

Why on earth would they implement a 2G toggle??

To save battery life.

 

[MikhailT]

To save battery life.

It doesn't really work like that, it may be true a while ago but I doubt it'd save anything right now. The chips/radio/antenna are more efficient, smaller, and optimized for the newest cellular protocols, switching to 2G wouldn't give you that much saving anymore.

 

[Menneisyys2]

Not necessarily. I'll measure its RAM usage and report back. (After sleeping first, I think - it's very late in here.)

Turns out I was right.

My benchmark app is ready. As usual, I've made the entire project available. It's available at https://dl.dropboxusercontent.com/u/81986513/122013/WebPageMemoryTester.zip and can be used for your benchmarks too.

I've made it VERY simple – it doesn't even have XIB's. The view controller, WebPageMemoryTesterViewController, (programmatically) creates an instance of UIWebView with the size of the full screen (minus the upper status bar, of course) and adds it as a subview to the current view. Then, it starts loading nin.com and starts a timer ([NSTimer scheduledTimerWithTimeInterval:0.5 target:self selectorselector(print_free_memory) userInfo:nil repeats:YES], which, by calling print_free_memory (based on http://stackoverflow.com/questions/5012886/knowing-available-ram-on-an-ios-device ) displays not only the free /used memory, but also their difference between the first and previous value of the current free memory and the original / previous one (this is what the origFreeMem and prevFreeMem globals are for. The third global, int seccounter;, makes it simply easier to spot time differerences as I've opted for using printf()'s instead of NSLog()'s to hide the usual NSLog prefixes).

I also directly call print_free_memory from not only the timer, but also immediately before and after creating UIWebView and immediately starting to load the web page into it. Also, I directly call it from the didReceiveMemoryWarning method so that we can see how much free memory the system had upon the warning.

I've run the tests on several of my devices, with various iOS versions and screen resolutions. I've reset every device before the tests so that they can have as much free RAM as possible. Three of the devices are JB'n but this fact didn't really have any effect on the results. After all, the free RAM of my non-JB'n 7.0.4 iPad 3 was 659349504, while that of my 6.1.2-based, JB'n iPad 3 was 625999872 – that is, some 35 Mbytes only.

The results certainly show what I talked about:

- UIWebView consumes a LOT of memory. Retina iPad 3's with 1 GB memory simply can't even load it because the page just won't fit into the memory, regardless of the OS version.

- the higher the screen resolution, the significantly(!) more memory used. This is certainly visible if you compare the iPad2 figures to those of the two iPad 3's. The non-retina iPad 2 allocates significantly less memory when loading / scrolling around the page and, if you don't scroll too quickly, you can actually have a chance to be able to read it entirely.

- the number of pixels of the 640*1136 iPhone 5 is around the same (727k) as that of the 1024*768 iPad 2 (786k). Still, the former consumes almost two times more memory to load / render the same webpage (I would have expected the iPad 2 to consume somewhat more memory because of the higher-res screen). Dunno if this is caused by the iPhone 5 running 7.0.4 and the iPad 2 “only” 6.1.2.

Links to logs + more thorough explanation:

The 5.1.1-based, JB'n iPhone 3GS couldn't even load the page. As you can check out in the full log at , in second 42, immediately before didReceiveMemoryWarning being invoked, we only had 3.5Mbytes (3555328) of free RAM, while the Web page has already been allocated 104Mbytes (104001536):

84; DIFF ORIG: 104001536; DIFF PREV: 471040
used: 73666560 free: 3555328 total: 77221888

The 4.3.3-based, non-JB'n iPod touch 4 crashed at loading too (after allocating 85M (85803008) bytes; full log: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ipt4g.txt ):

didReceiveMemoryWarning; 100; DIFF ORIG: 85803008; DIFF PREV: -647168
used: 60604416 free: 2506752 total: 63111168

The 7.0.4-based, non-JB'n iPhone 5 started with 626Mbytes of free RAM (626913280; full log: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ip5.txt ). It has finished loading the entire page at around the 55th second (around tick 110), allocating 335 Mbytes (335597568) in the process:

111; DIFF ORIG: 335597568; DIFF PREV: 0
used: 378970112 free: 291315712 total: 670285824

Then, I started to (quite slowly – fast scrolling would have crashed the widget) scroll down. During this, I've encountered several didReceiveMemoryWarning invocations. Then, the free RAM was around 70 Mbytes (70344704; a considerable drop from the 291M free after loading the page) and the widget allocated itself around 556 Mbytes (556568576):

129; DIFF ORIG: 556568576; DIFF PREV: 131567616
used: 577814528 free: 70344704 total: 648159232


After getting to the bottom and waiting a bit for everything possible to be released, I regained most of my, during the scrolling, missing free memory, which was around 274M (274776064); that is, not much less than the starting 291M:

145; DIFF ORIG: 352137216; DIFF PREV: -8192
used: 432508928 free: 274776064 total: 707284992

Then, a quick scroll to the top (by tapping the status bar) could have easily crashed the app as it, at the worst half-second, resulted in only 38Mbytes (38494208) remaining free:


153; DIFF ORIG: 588419072; DIFF PREV: 13512704
used: 527482880 free: 38494208 total: 565977088


The 7.0.4-based, non-JB'n iPad 3 couldn't load the page either (full log: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ipad3.txt ). Very soon after UIWebView had allocated around 650 Mbytes (648257536) and there remained only 11Mbytes of RAM (11091968), it crashed:

didReceiveMemoryWarning; 31; DIFF ORIG: 648257536; DIFF PREV: 79646720
used: 468738048 free: 11091968 total: 479830016

The 6.1.2-based, JB'n iPad 3, starting with a free memory of around 625 Mbytes (625999872), received its first didReceiveMemoryWarning callback at around 80 Mbytes of free (80945152) and, then, after half a second later, crashed at 8MB free (8798208), with the Web widget having allocated 617Mbyte (617201664) (full log: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ipad3-612.txt ):

didReceiveMemoryWarning; 25; DIFF ORIG: 545054720; DIFF PREV: 22192128
used: 465739776 free: 80945152 total: 546684928
26; DIFF ORIG: 617201664; DIFF PREV: 72146944
used: 517550080 free: 8798208 total: 526348288

The 6.1.2-based, JB'n iPad 2 “only” allocated around 200 Mbytes (201277440) of RAM to load the entire page with just a little bit (10Mbytes) of free RAM (10838016); see for example (full log: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ipad2.txt )

177; DIFF ORIG: 201277440; DIFF PREV: 0
used: 165519360 free: 10838016 total: 176357376

I started (slowly) scrolling down at tick 177; apart from occasional didReceiveMemoryWarning invocations, this could be done without crashing. So could I tap the upper status bar to quickly return to the top.

----------

If they're going to make it so RAM hungry, why skimp on the RAM?

(Just a quick note: see my benchmarks above.)

 

[Menneisyys2]

Because it is CRAP website...

Absolutely wrong. See my previous post: the page itself is Safari / iOS-compatible and has no incompatible constructs immediately crashing the browser.

This is why it's actually possible to browse it, in its entirety, on non-Retina iPad 2's or the iPhone 5, both under both iOS 6 and 7. If you don't scroll too quickly and reset the device before browsing, of course.

All these crashes are because of the Web widget's (on which Safari is also based) enormous memory usage. Which, as has also been explained, could easily have been remedied by increasing the RAM to, say, 2 Gbytes.

 

[shakeandbake]

Seems like a very minimal .1 upgrade. Used to be .1 updates included lots of new features, not just more bug fixes.

Weird.... I can't believe I was unaware of this.... & I've been downloading & updating software since the mid to late 90's.
Huh... So, .1 updates = lots of new features to BRAND NEW software. Hmm... sounds bizarre & counterintuitive, but you clearly know best.

/s

 

[patent10021]

Can we finally have movie/show titles below the videos in grid mode so we know what they are? Most home made movies or video tutorials etc don't have labelled covers. Would be so easy for them to add the meta from the iTunes show name in the video tab to the iPad. Some of us watch videos besides movies on the iPad!

 

[declandio]

Absolutely wrong. See my previous post: the page itself is Safari / iOS-compatible and has no incompatible constructs immediately crashing the browser.

This is why it's actually possible to browse it, in its entirety, on non-Retina iPad 2's or the iPhone 5, both under both iOS 6 and 7. If you don't scroll too quickly and reset the device before browsing, of course.

All these crashes are because of the Web widget's (on which Safari is also based) enormous memory usage. Which, as has also been explained, could easily have been remedied by increasing the RAM to, say, 2 Gbytes.

nin.com doesn't crash my phone/safari (iPhone5, 7.1.4) no matter how fast I scroll or how much cr@p is loaded in the background etc.