auxio

avon b7 said:

Personally I much prefer Android but Android comes in infinitely more flavors than iOS so it's impossible to have used them all to any real degree. The same applies to iOS and the changes from one versión to another.

I'd say that over recent years, iOS has taken a huge amount of influence from Android. Although it is a two way street, it definitely looks like Apple is loosening it's grip on key areas like personalisation.

For me, as someone who constantly has to dip into iOS to resolve issues, it can be very frustrating to see how some things seem so kludgy there. 

That could be due to my wife's particular situation/configuration or how certain apps 'behave' but it doesn't feel intuitive to me. 

From an application developer perspective (both Android and iOS), Android's technology stack is a mess compared to iOS. They put Kotlin on top of Java, which is basically just syntax sugar coating (Java was already a pretty high level language). Java has zero direct interoperability with native programming languages like C/C++, so if you do need to do more advanced things, or make things work cross-platform, it takes 2-3x more effort. And don't even get started on how awful Android Studio is ("Repair IDE" is one of the menu items in it, no joke).

Not surprising most people just create web apps in JavaScript on Android. Which is likely Google's plan anyways since it's easier for them to gather rich data on customers via the web than monitoring via Android itself (where figuring out what people are doing is more complex).

Apple's equivalent technologies (Objective-C and Swift) are very cleanly designed and intuitive, and integrate easily with cross-platform code, which isn't surprising since they were designed in-house rather than via clone and own (Java) and a 3rd party (Jetbrains created Kotlin).

I think most consumer problems with iOS stem from the fact that Google invests heavily in Chromium/web technologies, at the expense of their native technologies. Whereas Apple is the reverse. So if you spend your whole life in web apps and/or a browser then the experience is going to be better. Also, most web apps completely disregard any sort of platform UI standards. So again, if you're used to the wild west of web app/page interfaces, the native platform interfaces are going to seem less intuitive.

As someone who tries to avoid using web apps as much as possible because I find them slower to use, less intuitive, and battery killers, I find iOS very intuitive to configure and navigate.

lkrupp said:

asdasd said:

crowley said:

Illusive said:

So they want us to buy untested rubbish so then can alter it as they see fit with every update? No, thanks. Long live sandboxing!

Untested rubbish?  What is this based on, the blog post didn't mention anything about testing?  Rogue Amoeba are a solid developer with a great track record, and they definitely test their software.  

He is talking about Apple testing, but that is perfunctory. Just to see if the app works and isn't using private API or breaching privacy. 

Developers using unsupported APIs has been problematic for decades. Developers have hooked into macOS without using a supported API to provide some feature or function. macOS gets updated and the user finds out their app has ceased to function because the hook no longer works. Developer is forced to update and/or remove the feature, then rage at Apple. Lather-rinse-repeat. And who does the user blame? “It worked before the update, now it doesn’t, therefore it’s Apple’s fault. Fix it NOW, Apple!”

In recent years Apple has locked down macOS more and more (kernel extensions, browser extensions, etc.) so we see it less. Developers rage.

I'll give you a counterexample to the argument that no developer ever needs to use unsupported APIs.

I worked at a company which made wall-mounted touch displays that were used in education.  Since they're used in classes with smaller children (or special needs students), we needed to put the toolbar at the bottom of the window so that children (or people in wheelchairs) could reach it.  There was no way to do this with the standard Mac toolbar.  We could have just created our own toolbar, but we wanted the app to have the standard look and feel of a Mac app (especially since Apple changes it slightly on every new version of MacOS).  We talked to Apple about it, showed them photos, and they actually provided us a private API to do what we needed.

Sometimes there genuinely are cases where you need to do something which isn't possible with the standard APIs.

gatorguy said:

lkrupp said:

Just what we need, Android ports to iOS. Remember those Windows ports to Mac OS...? Let me guess. Google will encourage developers to build their Android apps and then port them to iOS using Flutter where they will look goofy and not perform as well.

Or they can develop for iOS first and easily port to Android too using Flutter. I know we have a few dev's here who can comment with more insight. 

I haven't looked into it deeply, but here's a key point:

Developers create the code of the app in Dart, which is then passed through Flutter's rendering engine and framework, with both tools used to make the code work on each platform natively. The engine is shipped as part of the app package, along with the developer's code, which is used to run the app on the target device, like an iPhone or an Android tablet. 

So basically you develop in a programming language which isn't native to iOS (Dart), which then requires you to bundle a special engine with your app to translate the application UI + logic from Dart into the native iOS APIs.  Sounds a lot like programming in Java.  I've used a few of these types of cross-platform runtime translation engines over the years, and the problem for me is that you'll never get access to the latest platform features because you're always waiting for the engine to support them.  And, of course, if such features aren't available on every platform the engine supports, then you may never get access to them.  Or you'll have to do a bunch of work to get access to them -- e.g. create your own JNI libraries in Java.

EDIT: Found the process for how to get access to native iOS features (looks a lot like creating JNI libraries): https://flutter.io/platform-channels/

These engines are perfectly fine for simple apps which are doing common things, but not-so-great once you want to get outside of that sandbox and do more interesting things which require platform features which don't fall in that platform common denominator scenario.  But since most of Google's apps just go out to the web/cloud for everything they do, it works for them.

Yet another “we want to profit from knowing what you do at all times” move. No thanks.

BiCC said:

bwilllius said:

The linked documentation describes super awful API calls to creation date and modification date of a file. Also getting free space is now a sin. All calls are harmless.

The MacOS kernal is a Sandbox.  Getting access to free space is going Blockchain style.  I would just like to add - if a kernal is a Sandbox you are 100 percent correct, the API calls are harmless. Why is Apple not giving you access to memory is mindboggling. Through JavaScript you can do a lot, and Apple admits it for URL. I think the management at Apple are spacing out!!  It's out reaching.  Good on you b.

Honestly have no idea what you're talking about. Let's define these words:

Kernel - The core of the operating system which manages system resources (CPU time, memory, access to devices, etc) for things which need to use them. Applications typically don't know/care about what happens at this level, and almost never directly interact with it.

Sandbox - A contained environment in which applications run. Applications get their own reserved storage, memory, etc and can't access the resources allocated to other applications (or the operating system). This is typically done at a higher level in the tech stack than the kernel, which has no knowledge of what applications even are. The kernel only knows how to manage access to low level hardware/resources for whatever is using them on the system (could be a device driver, could be a system daemon, could be an application, doesn't matter).

So calling the kernel a sandbox is meaningless. They're two completely separate concepts.

And applications always have access to memory/storage to do whatever they need to. What Apple is doing is limiting is apps which ask "how much memory/storage is left on the entire system?". The vast majority of apps don't need to care about how much is left, only that they have access to what need. The kernel is the only thing which needs to know how to manage memory based on how much is left on the system.

And then you throw in the term JavaScript, an interpreted programming language typically contained within a web browser environment. So the web browser controls what it has access to. Which is typically far less than what a native/non-web application has access to because the web browser can only give it access to things which are common across every single platform it runs on (from tiny embedded Linux systems to Mac Pros). The lowest common denominator of all those systems.

"Apple admits it for URL" - what does that even mean? A URL is an address for a resource on the internet (web page, image, etc). Sure, it's been hijacked as a means for web apps to send data (URL parameters), which are a classic source of buffer overflow security issues, but URLs have nothing to do with how much an app can do on the system.

red oak said:

All of these millennial or Gen Z snowflakes are torpedoing their careers.  They are going to wake up 10 years from now wondering how the f* everything up so bad 

God forbid anyone actual cares about anything except themselves.  I'm hoping the movement towards ethical Capitalism, which there's a fair bit of support for even at the investor level these days, gains some momentum from cases like this.

lam92103 said:

So every single PC or computer manufacturer can use modular RAM. Including servers, workstations, data centers, super computers. 

But somehow the Apple chips cannot and are trying to convince us that it is not just plain & simple greed??

And this really gets at the core of the mindset of PC users who have an irrational hatred of Apple: we do it this way, why does Apple think they're special?

That mindset typically carries into other areas of life too: why doesn't everyone speak the same language, worship the same god, look the same, etc, etc. They feel this need for everything to be the same, and for some reason want to force everything to be that way. I'd really like to know the reason why, because for myself, diversity is what makes life interesting. And in both nature and technology, it's proven to have great benefits for survival and progress.

There was a previous article on here which linked to an overview of RCS and how different carriers have branded it with different names, with varying levels of support for different parts of the specification.  From a technical standpoint, it looked like a hot mess at this point.  Google is fine with that because they're not the ones providing technical support for Android-based phones.  They can live in lala land and implement it so that it works perfectly fine with other Android phones running the very latest version of Android on Wifi, and not have to worry about being inundated with support calls from confused customers when conditions aren't perfect: cellular connection from a carrier which doesn't fully support it, phones stuck on older (incompatible) versions of Android, other types of phones, etc.  Apple OTOH has to worry about providing tech support when an iPhone using RCS encounters less-than-ideal connectivity situations which are outside of their control.

KTR said:

Damn, and they pay the 30% App Store tax

And what a blow that must be.  Paying Apple 30% of $0 since the app is free and there aren't any in-app purchases afaict.

I have no doubt that there's an endgame where him and his insiders get rich by tanking the economy, then buying up stocks and bankrupt companies at rock bottom. Everyone else just got conned.