Musing on Apple 2013

[jbjb]

Originally Posted by PatNY

I made assumptions about the app you referenced but did not describe, but I did not put words into your mouth -- along with false quotes -- the way you tried to do with my statements. There's a big difference there. HUGE.

They weren't false quotes - as I explained, I think it was clear from context that I was paraphrasing. If you believe otherwise, I'll be more explicit in future. If you really believe that there was any deliberate attempt to mislead by misquoting you, then I find that genuinely offensive.

Huh? I never tried to argue that iOS apps never used springs and struts in its interface. Where did you get that from? So why would I need convincing of that?

This is what I asked you to prove (exact quote):

"Just name a widely used consumer app that was scalable prior to iOS6. OR reference an article that supports your claim that scalability was practical OR widely used prior to iOS6."

Still waiting.

Again, you miss the point. It's not possible to know (without inside knowledge) which apps were or were not using S&S for iOS5 and earlier, so how can you expect me to name one - even if I did you wouldn't believe me.

My assertion isn't that any particular app you might recognise was using it - it's simply that it was useable, and was used. I know that, as I and many other developers of my acquaintance used it - just because these apps aren't available to the public doesn't mean it wasn't used in consumer apps. My line of work (at least as it involves mobile apps) is very specialised and doesn't involve consumer apps, but I have no reason to suspect they'd be any different.

As I've always said, however, many developers chose to exploit the limited range of screens and chose to design optimal UIs for each.

I've had enough of this - your mind is clearly predetermined.

My position is plain:

• iOS currently supports interface scalability
• For iOS5 and earlier, it supported a more limited form of scalability that was useful in some instances, but less widely than the auto layout introduced in iOS6.
• The relatively restricted range of screen parameters available for iOS makes designing an optimal layout for each of these more feasible than it is for Android, and many developers chose to do so.
• Claims that iOS doesn't support interface scalability are bogus.

That's it. Unless you come up with something worth answering, I'm giving up trying to convince you.

/JB

[PatNY]

Originally Posted by jbjb

They weren't false quotes - as I explained, I think it was clear from context that I was paraphrasing. If you believe otherwise, I'll be more explicit in future. If you really believe that there was any deliberate attempt to mislead by misquoting you, then I find that genuinely offensive.

You were attempting to describe my position and you used quotes for words/phrases I never used. In that context it could be extremely misleading. I found that highly offensive, regardless of any intent.

Again, you miss the point. It's not possible to know (without inside knowledge) which apps were or were not using S&S for iOS5 and earlier, so how can you expect me to name one - even if I did you wouldn't believe me.

I am not asking you to show which apps used S&S. I am asking you to prove that there were easy and practical methods to scale iOS apps before iOS6. It should be an easy thing to do -- if in fact that were the case.

My assertion isn't that any particular app you might recognise was using it - it's simply that it was useable, and was used.

My assertion is that if it was not an easy and practical method to scale apps, then it was essentially useless for that purpose. It appears that was the case as you can't even give one link that discusses viable scaling methods prior to iOS6.

Again, we are not talking esoteric private apps shared among a few people. We are talking about apps widely used by the general public.

As I've always said, however, many developers chose to exploit the limited range of screens and chose to design optimal UIs for each.

Apparently, that was their only practical option up to iOS6. There was no other practical alternative. Essentially, they had no choice.

I've had enough of this - your mind is clearly predetermined.

So it appears is yours.

My position is plain:[LIST][*]iOS currently supports interface scalability

Agreed.

[*]For iOS5 and earlier, it supported a more limited form of scalability that was useful in some instances, but less widely than the auto layout introduced in iOS6.

Irrelevant. If it wasn't practical for the general iOS developer -- then I (and others) are correct in saying Apple's limited or non-existent scalability prior to iOS6 was a hindrance to the introduction of more varied screen sizes and resolutions.

[*]The relatively restricted range of screen parameters available for iOS makes designing an optimal layout for each of these more feasible than it is for Android, and many developers chose to do so.

This was never disputed.

[*]Claims that iOS doesn't support interface scalability are bogus.

What is true is this: Before iOS6 was introduced, iOS did NOT support easy and practical scalability in its apps the way Android has done from its beginning. This hindered Apple in its introduction of new screen sizes and resolutions.

This is not too different from my original claim -- the only difference being the time frame in question.

Because you refuse to attempt to prove that scalability was a viable alternative for developers prior to iOS6, I did a little research on my own. Now I know why you hemmed and hawed, refusing to look for any links to support your view. Because they essentially don't exist. You can't find something which doesn't exist!

If anything, scalability prior to iOS6 was only the province of a few developers like yourself producing esoteric private apps. It was not applicable to the general iOS development community or to consumer app development. Your point about it is essentially moot within the context of the conversation which spawned the issue -- the reasons why Apple did or didn't introduce more varied screen sizes in the past. Just because a few developers may have found a way to scale within the parameters of early iOS versions did not mean anything to Apple's train of thought at the time.

I did read an interesting comment from a developer who apparently has experience producing both Android and iOS apps. It came as a reply to an article announcing the introduction of iOS6 and Auto-Layout. The bold emphasis is mine:

The claim that the first release of iOS then contained any support of not only multiple resolutions, but also adaptive layout, resize and reflow capabilities (that is prevalent in WPF) is also highly suspect; there was only 1 device with 1 resolution to actually code for.

Not only that, if iOS had built-in support for the above from the beginning, iPhone apps would not have had the weird "stretched" look when used on an iPad. The fact was that the different aspect ratios between the iPhone/iPod Touch and iPad did not translate well if you did not code two distinct versions; Apple's iOS graphics framework did not contain inherent resolution-adaptive support. Every project we did we had to provide separate assets and UI code for the early low-res iPhones, then the higher-res iPhone and later-gen iPod touches, and then again for the iPad. Apple is only releasing AutoLayouts now because people are realizing that iOS IS fragmented, and they need to start building proper support if they ever intend to introduce more devices with different resolutions and aspect ratios - likely in the upcoming iPhone 5 - or be prepared to lose cross-developers developers like us....


On the other hand, (although not as robust as in later versions with the availability of Fragment in API 11), Android already had built-in support for multiple resolutions within a year of its release - simply because it was required. You could include multiple layout variants from the get-go, programatically and dynamically size views (what they call their controls/UI components) according to current display resolution and density settings. Since there is multiple resolution and layout support by default, an app developer can choose to use a single set of assets just layout and sized differently for different device, or simply provide different sets of assets that and use scaled layouts the same way as iOS does. Fragment support made it easier for developers to release a single app that caters to multiple devices with different specs - but the existing framework was already well capable of doing that, it just takes more work.

The link to the article and comments is here.

He is essentially saying the same things I said. I will take his word over yours.

In every article I saw about iOS6 and the new Auto-Layout feature (including the one I gave a link to) it was hailed as a breakthrough for iOS. A game changer. If scalability had been a practical alternative in the past -- or used widely in the past -- that would not have been the case.

--Pat

[jbjb]

Aaargh! I promised myself I wouldn't continue with this pointless discussion, but I can't resist having one more go.

Originally Posted by PatNY

I am not asking you to show which apps used S&S.

What were you asking for here, then:

Just name a widely used consumer app that was scalable prior to iOS6

Moving on from that, however ...

I am asking you to prove that there were easy and practical methods to scale iOS apps before iOS6. It should be an easy thing to do -- if in fact that were the case.

If you want evidence that it exists and is easy to use, just look at the developer docs for how it's used, and judge its ease of use for yourself. Or, if you have access to a Mac, or know someone who does, download Xcode and try it out (it's free, and you can knock up a simple S&S UI that scales in a few minutes). I completely agree its usefulness is limited to certain types of UI, but it would be a mistake to underestimate the importance of those types.

If you want evidence that developers were using it, just google for "Xcode springs and struts". You'll find thousands of discussions amongst developers using it.

Having said that, I don't know why I'm bothering to try convince you of this point - it's irrelevant to my argument. I only stepped into this discussion to correct the misinformation that Apple are currently held back by an inability for iOS to scale interfaces. What it did in an OS two generations out of date is not relevant to that point. Feel free to continue to believe whatever you want about springs and struts - I'm not really bothered.

Again, we are not talking esoteric private apps shared among a few people.

By "private" do you mean not available to the public via the app store? It would be a mistake to assume that all such apps are only available to a few people. They can have wide distribution, and are an area that is important to Apple.

This is not too different from my original claim -- the only difference being the time frame in question.

The time frame is, however, a crucial difference. In a thread about the current state of affairs for Apple, it seems perfectly reasonable for me to have pointed out that a limitation you claimed currently applied to iOS hasn't applied for at least the last two generations.

Apologies to anyone still listening for dragging this out further, and for allowing myself to be dragged down irrelevant side alleys. I really will try and resist the temptation to carry on, unless something new is added to the argument.

/JB

[PatNY]

Originally Posted by jbjb

What were you asking for here, then:

EXACTLY what I said: The name of a "widely used consumer app that was scalable prior to iOS6"

OR, as I also said, even a link to an article on the internet discussing practical scalability prior to iOS6.

You could provide neither.

If you want evidence that it exists and is easy to use, just look at the developer docs for how it's used, and judge its ease of use for yourself. Or, if you have access to a Mac, or know someone who does, download Xcode and try it out (it's free, and you can knock up a simple S&S UI that scales in a few minutes). I completely agree its usefulness is limited to certain types of UI, but it would be a mistake to underestimate the importance of those types.

No, if it existed, there would be references and articles about it. Instead, all there is are references to how finally with iOS6 there is a practical way to scale apps. That -- in addition to your inability to find any articles to support your contention -- underscores how wrong you have been.

Having said that, I don't know why I'm bothering to try convince you of this point - it's irrelevant to my argument.

It's relevant to mine.

Feel free to continue to believe whatever you want about springs and struts - I'm not really bothered.

Your behavior says otherwise.

Also, it's very telling how you keep zeroing in on "springs and struts" when that really isn't the issue here. And I've made no statements about "springs and struts" whatsoever. The issue here is whether there was a practical way to scale iOS using "springs and struts" or any other method. You keep sidestepping the real issue.

By "private" do you mean not available to the public via the app store? It would be a mistake to assume that all such apps are only available to a few people. They can have wide distribution, and are an area that is important to Apple.

If consumer apps were not easily scalable at the time, then it has no relevance what you or anyone else did in private.

The time frame is, however, a crucial difference. In a thread about the current state of affairs for Apple, it seems perfectly reasonable for me to have pointed out that a limitation you claimed currently applied to iOS hasn't applied for at least the last two generations.

When talking about the current state of affairs, the past naturally comes up because it informs the present. The limitation did apply for the majority of the life of iOS and is a reason Apple limited screen sizes and resolutions in the recent past.

And, actually, the limitation applied as recently as a year ago. In case you need a reminder, iOS6 was just introduced in September 2012. So it's still a timely issue.

I've given you a link to the comments of a developer which support my position. Too bad you continue to claim the earth is flat. But c'est la vie. There will always be those sticking to ideas which can't be supported.

--Pat

[frahse]

Just over in CNET.

Two things of note.
The high end Mac Pro will get Haswell soon.
(Every mother's child should have Haswell. I will not buy another laptop or chrome book without Haswell.)

Apple will soon not have any computers with a hard drive.
I had thought they meant a storage drive, but they actually are talking about DVD drives as well!

Do you think that is a little over the top?

[ilovejedd]

Originally Posted by frahse

I had thought they meant a storage drive, but they actually are talking about DVD drives as well!

Do you think that is a little over the top?

I haven't built a computer with a DVD drive since 2010 so nope, not really.

[kyteflyer]

Originally Posted by frahse

Just over in CNET.

Two things of note.
The high end Mac Pro will get Haswell soon.
(Every mother's child should have Haswell. I will not buy another laptop or chrome book without Haswell.)

Apple will soon not have any computers with a hard drive.
I had thought they meant a storage drive, but they actually are talking about DVD drives as well!

Do you think that is a little over the top?

I have a mac mini with no drive. My previous MBP had one and I rarely used it. I have an external which I had bought to go with my netbook, but I rarely use it.

I think the 13" macbook Pro is the only Mac left with a superdrive. Apple make an external one (I have a Sony) which is an optional extra. I download nearly all I want, most software companies offer a downloadable version rather than a boxed copy. I nearly never buy a DVD or CD for anything, not even music anymore. I've already transferred almost all my old CDs to computer. They just arent needed. If I have to move stuff from A to B, or store it for future reference, it will go on a USB flash drive, an external HD or a portable HD. The day of the CD or DVD is nearly over.

[Graham]

Originally Posted by frahse

Apple will soon not have any computers with a hard drive.
I had thought they meant a storage drive, but they actually are talking about DVD drives as well!

Do you think that is a little over the top?

Not any more. I was worried about the 16 GB SSD being all I had in my Chromebook. 9 months later I've used less than a gig, and that's all temporary downloads - there's nothing there I'd need to restore if I had to wipe it.

We're moving beyond nasty, spinny, hot, noisy things. A nice silent SSD can provide all the storage we really need locally.

Graham

[Josieb1]

I'm 50 and I hope we don't see the end of PC storage (MAC or Windows) and DVD drives in my lifetime. I still buy music and films/tv on DVDs and I have a 750gb hard drive 3/4 full!

[tubemonkey]

I no longer buy physical media. I stopped doing so years ago.

[forsooth]

In past I got 1 program on 20+ (3 1/2 inch) floppys.

[frahse]

Originally Posted by Graham

Not any more. I was worried about the 16 GB SSD being all I had in my Chromebook. 9 months later I've used less than a gig, and that's all temporary downloads - there's nothing there I'd need to restore if I had to wipe it.

We're moving beyond nasty, spinny, hot, noisy things. A nice silent SSD can provide all the storage we really need locally.

Graham

Obviously you don't have a 60GB music disk. (Mind you, no videos in there.)

[Jessica Lares]

Originally Posted by forsooth

In past I got 1 program on 20+ (3 1/2 inch) floppys.

Me too.

My hard drive is just my photography, and stuff I've ripped off YouTube, iTunes U lectures and podcasts, and music. Oh, and my DRM-ripped stuff.

[Penforhire]

frahse, I think the trend is good. Dropping spinning discs makes a laptop smaller, the battery lasts longer, and I no longer fear any mechanical shocks. I personally won't buy another PC (laptop or desktop) that doesn't use SSD for its primary drive. The difference in general snappiness is amazing and prices have dropped enough to consider a 128 GB SSD a commodity.

If I need a CD/DVD I hook up a generic (cheap) USB external drive. I use multiple external hard drives for storage outside my PC's (I really should migrate to a NAS system) and flash-memory cards for in-PC extra storage (for any MBA users, two thumbs up for the Nifty Minidrive card tray with a 64 GB card, slightly expensive but very nice).

[frahse]

Originally Posted by Penforhire

frahse, I think the trend is good. Dropping spinning discs makes a laptop smaller, the battery lasts longer, and I no longer fear any mechanical shocks. I personally won't buy another PC (laptop or desktop) that doesn't use SSD for its primary drive. The difference in general snappiness is amazing and prices have dropped enough to consider a 128 GB SSD a commodity.

If I need a CD/DVD I hook up a generic (cheap) USB external drive. I use multiple external hard drives for storage outside my PC's (I really should migrate to a NAS system) and flash-memory cards for in-PC extra storage (for any MBA users, two thumbs up for the Nifty Minidrive card tray with a 64 GB card, slightly expensive but very nice).

I have been (more so in the past now) used to 2 disk systems. 1. The System Disk 2. The Data Disk.

I could readily see a 16 or 32GB SSD and a 1 Tetra Byte Data HDD. The HDD would kick in only when there was a need.
And don't talk to me about a "cloud." Some places I go, clouds don't.

The problem with add ons is that they are not so portable as a system with everything in 1 case.