Talk about "Bendy"...

Insightful? Really???

You say you are "an engineer"; but are you an ME, a metallurgist, or do you drive a train?

If, by chance, you actually are an engineer that is on a team that produces consumer-level products, can you honestly sit there with a straight face and say that your products are regularly tested to the level demonstrated in the Verge article?

I have designed many products that were to survive in the supposedly much-harsher world of an "industrial environment", and I can tell you that not one of them was subjected to the destructive and non-destructive physical testing that the Verge article showed to which Apple products are being subjected. And I don't think the companies I worked for were the exception in the "lack" of testing. In fact, Apple's testing seems almost over-the-top. Probably why almost all of their products have a (deserved) reputation for being extremely rugged, relative to the competition.

Do I think that they have a minor issue with the strength of the case at the point at which the volume-button punch outs are made? Yeah, probably. Is it worth all the hand-wringing? Definitely not.

Let's take these one-at-a-time:

1. Apple ///. According to Woz (who should know), the Apple /// was a victim of the engineering directive (not Jobs', BTW, but a team-consensus) that it must have 100% compatibility with the Apple ][ (a laudable goal); but, the kicker was that it must not allow any of the Apple ///'s capabilities to be available when in "Apple ][ Emulation mode". That resulted in massive amounts of extra circuitry (remember, this was 1978 when the Apple /// was being developed) to accomplish that goal. The end result was a design that was beyond the PCB manufacturer's capabilities for the day. There was nothing wrong with the design,per se; it just out-stripped the manufacturing capacities of 1979-80. And by the time the Rev. 3 PCBs came around, it was actually a very solid machine (with an incredibly-advanced OS (AppleSOS)). Unfortunately, by then it was simply too late, market-wise. It is interesting to note that the trace-density that was impossible on the Apple /// PCBs is absolutely trivial these days.

2. The Lisa: Nothing at all wrong with the engineering of the Lisa. It's a damned tank!. Have you ever been inside of a Lisa? Probably the best-engineered computer ever. The only problem with the Lisa was the Price. That, and the fact that it was "too far ahead of its time." Seriously. Next! (no pun)

3. The G4 Cube. This one is all on Jobs. It was made impractical by Jobs' hatred of fans (and before they figured out that fans could be made quiet by making them bigger and turning them slower (duh!), and by doing stuff like uneven spacing of the fan-blades (not so "duh"). And secondarily, it was killed by Jobs' longstanding vision of a small-self-contained computer. But I guess he doesn't get credit for pulling that off again and again in the Mac mini, original G4 iMac (the "Sunflower" iMac), the flat-screen iMacs, the MacBook Air, and most recently, the incredible Mac Pro (which of course had to be well into final phases of design when Jobs died), right? No, no credit at all. And then, let's never forget that it was also Jobs and Apple who pretty-much single-handedly, completely revolutionized the phone and tablet. To deny that is to simply deny reality.

Bottom line: Every single company that produces as many "hi-tech" products, for as many applications, for as many years, as Apple, will have some products that are absolutely great, and some, not so much.

Doesn't this statement pretty much say it all?

A friend of mine that was an ME for Delco, said something a long time a long time ago that has always stuck with me: "You can always tell when something is built by someone who doesn't know what they are doing, because it will always be 'over engineered'."

So, I guess it is an entire engineering discipline, not just Apple's engineers, that have "Fallen into the fallacy..."

Did you even read the Verge article, which specifically stated that Apple adds stiffeners, sometimes even made of steel or Titanium, when its destructive, and non-destructive, testing shows that is warranted?

Truth is, you can't fix stupid; nor can you design a series of tests that will duplicate every single scenario that a product will encounter in the "real world". That's not making excuses for Apple; it is just the way it is.

The Verge article clearly demonstrates that Apple has done its Due Diligence; but that it is pretty much impossible to make something that is indestructible.

Oh, and BTW: Where was your Righteous Outrage at the makers of the HTC One (M8), that apparently bends with approximately the same force as the new iPhone? Where was the hand-wringing then?

I capitalize to denote proper nouns, and sometimes just for emphasis.

So, how is that helpful for deciding which language I should use?

IOW, bite me.

Hey, my article submission said "Dalvik". Slashdot editors put in the unwanted "c".

So, you, the Great Programmer, thinks that Objective-C is "proprietrary"?

This proves just how little you know...

Thanks. I think that is the most cogent advice yet.

Not in the real-time measurement and control world, where the vast amount of my experience lies.

Until very recently (and really only since the advent of the iPhone), Microcontrollers simply didn't have the resources to stand the cycle-stealing overhead of languages like C++; so, the vast majority of devs. that were having to write stuff that had to keep up with the real-world (or else Bad Things would actually happen; not just a Sprite-Draw would be a little late) write in either Assembly and/or C, and most still do.

I still get a chuckle when job requirements for real-time Projects insist on C++. It's usually a sure sign that the requirements were written by HR from a series of Buzzwords; or by a clueless PHB.

As I said, just like the Porn industry drives multimedia capabilities, the smartphone/tablet industry is creating SoCs (can't even call them MCUs anymore!) that, while they are incredibly powerful, are still out of reach, budget and size-wise, for the vast majority of embedded designs.

So, it is you that is an anachronism; because the world you think we live in, and its obligatory Flying Cars, sadly won't exist for another decade, at least. And until then, you are better served as an Embedded Dev. to know C and Assembler, than to know C++, Java, or, quite frankly, any other Object-Oriented Language.

No Poser I.

Not to brag, but I have been an Embedded Dev. For over three decades. I have written tens and tens of thousands of lines of Assembly Language for everything from 8 bit 6502 to 32 bit ARM9 Cortex, and everything in between. Various MCUs and CPUs from Microchip, Mot., Zilog, Intel, ST, Atmel, to name but a few. I have personally rewritten 6502 assemblers to cross-assemble for 6809 and 8051. I am experienced in many, many different IDEs, debuggers, ICEs, etc. My specialty is real-time measurement and control systems, with or without RTOSes.

But sometimes, just like the many Nuclear Physicists that still occasionally slip-up and say "Nuke-U-Ler", I occasionally flip the terms "Assembler" and "Assembly".

So, Mr. terminology-Nazi: You are hereby cordially invited to Bite Me.

OP here.

You are correct, at least partially, Barbara. This IS more of a case of "I have a cool idea..." But I thought I made that clear.

And there is neither the budget nor time to do what you, and others, have suggested; contract it out, as sensible a suggestion as that may be.

But, not every useful App needs a top-notch Developer; and I have been a Developer (and quite often the only one) on enough Projects, for enough disciplines, for enough decades, that I can tell you with confidence that in any reasonable Language, this is a medium-low-complexity Project. The people that have said that I will spend more time mastering the necessary Frameworks than learning whichever Language, are exactly singing to me...

I do, of course, intend to start learning the IDE and APIs (at least for iOS) before I seriously commit to a programming Language; but I just thought I could take advantage of the Collective Intelligence of the Slashdot Community, mainly to see if there was a clear consensus as to whether, at this point in time, there was a clear "winner".

I am intensely grateful that the vast majority of the Posters Responded with thoughtful and non-condescending advice. Too bad you were too busy with your arrogant belittlement and holier-than-thou self-aggrandizement to offer anything worthwhile.

Thanks...

OP here. Thanks to everyone for all the wonderful info and suggestions!

I didn't think it was "legal" to target an App Store-bound iOS App in anything but Obj-C and now, Swift. Could I hypothetically write an iOS App in ARM Assembly?

I'm not a huge OOP fan in general; so the more I can avoid the Heartbreak Of OOP, the better.

Are there any resources for learning how to use the CocoaTouch APIs from C?

So this is the bash rough equivalent to an SQL Injection Exploit?

Wow! The Microsofties are out in force today!

This vulnerability also exists in non F/OSS OSes, such as OS X.

And as I posted above, no MS fan should ever mock a vulnerability in another OS.

Ever.