anonconformist
About
- Username
- anonconformist
- Joined
- Visits
- 111
- Last Active
- Roles
- member
- Points
- 585
- Badges
- 0
- Posts
- 202
Reactions
-
Highly suspect benchmarks stoke rumors of Apple-designed ARM chips for Mac
The size and complexity of the app is 100% irrelevant for porting between chips if the code is 100% portable.melgross said:
Despite what many people think, most apps are not a recompile away. Yes, small, simpler apps may be. But think about all of the demo’s we’ve seen over the years from software developers who, on stage, said; ...and we did this in one weekend, it was so easy! And then the actual app didn’t arrive for 6 months. Because it’s NOT so easy. Recompiling for a different chip family is never easy.jkichline said:Seems to me that if you’re going to transition to ARM, you need enough horsepower to handle x86 emulation for apps not recompiled to support ARM. I suppose this would be trivial to recompile existing apps using an updated version of Xcode, or to compile iOS apps to Mac soon which already using ARM instructions.
The instruction set is different. Some instructions aren’t even similar. X86 is Ciscier, while ARM is Riscier. Moving from one to the other is not simple for bigger apps. So big apps such as Office, and Photoshop, and Final Cut will have to run under emulation for some time, at half speed. We’ve seen this several times now, so don’t be surprised.
putting these into a Macbook, which uses a weak CPU could work, because this would be a lot more powerful, so that emulation would be fine. Big apps likely wouldn’t suffer much.
it’s only ever relevant that porting is difficult if they’ve coded low-level bit-twiddling and special SIMD math operations in CPU-specific instructions, because often compilers don’t emit optimized instruction streams from code to do that: not all C/C++ compilers are created equal.
The most common practice for applications include first writing and testing algorithms in whatever higher-level language being used (where “higher-level” is higher than assembly) and then you profile the application, and only if the higher-level language implementation doesn’t provide high enough performance, would you then rewrite the time-critical inner loops in the local CPU assembly language using special instructions the compiler doesn’t know how to translate the higher-level coded algorithm into the optimized assembly that a compiler does for most things. The practical reality is these days with speculative execution and out-of-order-execution, humans are going to produce less optimized code than a modern compiler does.
The higher-level code is #ifdef’ed out (C/C++/Objective-C/C++) and the optimized assembly code is #def’ed in, if a developer has it: this is normal practice.
Very little code in any application of any size is going to be written in hand-written assembly: doing more than that is non-sensical from an ROI standpoint. How muc is likely to be in assembly? A small fraction of 1%. 1% would be a HUGE amount of assembly in an application >10,000 lines of code.
-
Apple Enterprise Certificates leveraged to distribute hacked versions of popular apps
Note to self: determine if there’s a way to detect if your certificate is the one being used, and make the iOS application mangle data randomly if not!
-
iPhone XS versus iPhone X - which phone unlocks faster with Face ID
Face ID seems to work well with hats and glasses, I've not had a chance to test with a scarf yet (I don't wear one often, it doesn't get that cold around here on average). Touch ID tended to be problematic when I went climbing, in that chalk dust or just sweat resulted in it refusing to recognize my print.
Now, Face ID seems to work just fine regardless of how hard you're sweating, night/day, I've not tested with a bit of food on my face, so that might be an interesting silly test to perform.
There is one thing Apple clearly did not intend it to work with, though: CPAP masks! It doesn't work with a full face mask, even one that's almost entirely transparent. I suppose this gives a slight amount of security from kids trying to use their parent's Face ID when they're not fully awake (they might open their eyes but not be all there) if they use CPAP
-
iPhone XS versus iPhone X - which phone unlocks faster with Face ID
I predict the answer is never, because there are no low-powered lasers in use, just projecting infrared. That's not what lasers do, and that's not focused like a laser (look up what a laser actually is...) and infrared is... heat radiation. It's like looking into a little bit of heat.saniat said:When will AppleInsider deal with the safety issue of Face ID? Does everyone really believe that constant facial scanning with a low power laser, over months and years, is perfectly safe for vision? It's never been done before. The eye's retina and other structures are very sensitive to light. Damage to the eye is not "all or nothing". Constant exposure to a low level laser may cause cumulative damage. I've seen zero discusions about the safety of Face ID technology. Is the safety issue of no interest to anyone? Really?
-
Apple held secret meeting with developers in 2017 to push app subscriptions
I'm a developer, as well as a long-time platform user of both iOS and MacOS.
I'm currently developing a western music notation composition application (with playback) that will support full notation at least according to a well-known music notation book, and will be able to be used for composing symphonic works.
Why would I do such a thing, when there are a fairly decent number of other applications that exist for the task?
Simple: they all suck in one or more ways, even though most have been out for several years. They suck in:- Usability
- Completeness/correctness for standard music notation
- Limited number of parts
- Stability
- Sound quality
- Slowness for entering/editing music
They're all pretty cheap, considering what they should be able to do for the user.
They're all pretty expensive, when you consider how much time/energy is lost fighting those issues to compose something.
The majority of their updates have been to fix bugs that shouldn't have ever existed in the first place: really, western style music notation is a rather well-known solved problem: there are several thick books that fully document layout rules!
Experience in watching what happens on the App Store is that things that are updated get attention from would-be customers. Well, I know how to develop software that, with a given feature set, I won't have a useful reason to be updating it to fix crashing bugs, and since (again) the problem is so well-defined, I see no valid reason to spend a huge amount of time trying to wrack my brain to come up with upgrades, which Apple doesn't have a good model for, where subscriptions would make more sense.
And then there's the sad reality: the majority of App Store customers are cheap bastards with exactly no concept of how much time/effort/money/energy it takes to become skilled enough to develop a great application, and a huge number on the store are either developed by those with very little experience (and it shows) or, because of the race to the bottom pushed on by the typical customer, it makes no financial sense for a developer to spend the time/energy/money for proper testing, so people complain about the quality, while also whining they're still too expensive (and yet, they're stupidly, unsustainably cheap) when there's pretty much no chance for a developer to come close to breaking even in the endeavor, because App Store customers are cheap bastards.
Thus, it seems probable that unless something really changes in a very interesting way, freeware with ads will give some developers a tiny income that doesn't cover expenses for most applications because people won't go for subscriptions, are too cheap to pay a fair price for the functionality of an app of a given complexity, and all that's left are applications for big companies for shopping (like Amazon.com) where it doesn't matter that the applications are "free" because they're just a tool to get customers to spend money otherwise.
What's a developer supposed to do, starve to make cheap bastards happy? At the end of the day, it doesn't matter how good/bad/ugly the OS and platform is: if it isn't financially-viable to risk developing software for it, the platform will go away into the dustbin of history as it stagnates and dies due to no commercial viability in the ecosystem, and then the process repeats on the next platform.
This post is brought to you from someone with a perspective as a developer that's worked on multiple platforms that no longer exist, due to having that long of experience. The cheaper customers are, the more they need to spend eventually, because they are forced to change platforms entirely over time and leave all their old software and hardware behind.
