macOS' support lifecycle is terrible

in 2025, many OSes out there have become rolling release, where you're expected to be always up to date or else things break or your computer yells at you to update (sometimes forcing you if you're a windows user)

microsoft is probably well best known for this. windows update.is aggressive as hell and loves to force you to update whenever the automatic update service decides is appropriate to do so. apple pioneered rollback prevention with SHSH blobs preventing iPhone users from downgrading their OS beyond what apple currently is signing. chromebooks update themselves quietly and typically seamlessly, the only indication of an update being a new feature or (somehow) even more horrifying slowdown. rolling release is just a market standard now.

but for everyone who isn't "your average consumer," rolling release can be annoying, and a downright nightmare for enterprises and pro users relying on a fixed configuration for everything to work smoothly. as much as i'm sure they don't want to, companies offer solutions for these cases, typically for a pretty penny. but it's better than nothing. microsoft offers the long-term servicing channel (LTSC) for windows 10 and 11, offering 7-10 years of support for each release, google offers a long-term support channel for chromeOS wbere devices get regular security updates but only get version bumps every 6 months. this way, you stay secure without having to factor in potentially breaking updates.

apple...does not offer any such options. despite macs being the de facto productivity machine, apple just does not offer long-term support. you get 3 years of security updates, and that's it. you're expected to hop up to the newest macOS release when that time comes, or yearly if you're the plain guy who simply needs a mac for work. but for everyone else, three years is not enough for macOS. with each release dumping huge overhauls to the system, and with how deprecation-happy apple is, a mere 3 years isn't enough to ensure long-term support for those who need a stable, consistent system for their needs.

for example, in 2021, apple released macOS 12 Monterey, which removed the bundled PHP from the system entirely. this left webmasters with two options.

    1. keep on macOS 11 Big Sur where PHP was present and keep it for as long as possible, kicking the issue down the road.

    2. upgrade to monterey and break the server, then spend god knows how long searching for a method to reinstall PHP, discover that said version behaves far differently from the now-available versions, and spend MORE time trying to fix that.

both options suck. in a perfect world, Big Sur would simply have 7-10 years of support, allowing more time for a seamless transition to a more modern platform. we'd have ample time to move over, and extra time if needed for any legacy systems and programs for which full replacements are needed if new macOS versions break them. macOS server didn't even offer LTS, prior to its relaunch as a add-on for existing versions, the standalone versions had the same support cycle as their consumer counterparts did.

apple just needs to start an LTS channel. they have the resources, they have the money. it would be great for the many IT professionals currently stuck upgrading every mac they have every 3 years because LTS just doesn't exist.

psa for lsposed users

icymi, lsposed is EOL and dead. the original maintainers haven't done anything with it in a good minute. many people recommend the mywalkb lsposed_mod fork, however it has many issues and features tend to be broken. my personal choice is JingMatrix's lsposed fork which fixes a lot of issues and has overall better support

horrifying encounter with google support agent

this is written from the POV of someone with debilitating social anxiety. to my broken-ass brain, this was the most horrifying situation i had been in within the last 24 hours. /hj

i headed into those google one support chats which are purportedly able to assist human-to-human with any question about any google service. that...was a grave misunderstanding. turns out these probably minimum wage-paid guys are really only there to assist in subscriptions and payment for google one itself. why they advertise otherwise? i don't know. maybe i'm in the wrong place. fuck if i know, i'm an idiot, you see.

so i fumble out an explanation with shaking hands (WHY am i afraid of this poor support agent?) and get met with the "I'm here to assist with Google One subscription-related issues." that was the moment my soul left my body. i had spent the past 10 minutes trying to explain a random issue on a google product barely used since the 2000s, and on that note, with a feature that had literally been unmaintained since 2008, probably.

he had no idea what i was talking about. I had no idea what i was talking about. no one had any idea what was going on. my shitty communication skills resulted in a dumbfounded support agent and a dying-inside me, both staring at our screens in sheer confusion.

i panicked and left the chat. this is my daily struggle of mundane tasks. so i sit here...a moron, writing in my handcrafted echo chamber about an insignificant 10 minute experience that will, for some ungodly reason, probably haunt me for the rest of my life.

cool.

pixelifier - fixing aosp

i've developed a simple magisk module. it's called pixelifier. it's a neat little module to make your AOSP-based phone nicer.

features

• google sans (& text) fonts - properly implemented! roboto is kept intact.
• fixed clock font with variable weight supported
• pixel UI sound effects and ringtones included
• round adaptive icons globally, system-wide
• lowercase button labels within system applications and system UI

 the module is available on github for download. you can download it from the releases page.

one ui 7 from the pov of a z flip5 user

one ui 7 had some of the biggest hype for a one ui release in a long, long time. partly (mostly) because they took so damn long to release it. android 15 released publicly around september 2024. one ui 7 didn't start rolling out until APRIL 2025.

two hundred and twenty days behind android 15's general release. tack on another 4 days because us Z5 series users wouldn't get it until april 15, 4 days later. one could defend samsung for delaying one ui 7 to "iron out the bugs," but one ui always has bugs. it has never been stable. hell, android 15 itself was pretty buggy on release. one ui 7 would be buggy no matter what.

as for me, i'm pretty sure my device still hasn't gotten it yet. i've got NO updates OTA and no odin-flashable firmware have surfaced. i have the SM-F731U1 XAA model. i ended up flashing the same model, but XAR for the CSC instead no issues for me so far, it works fine on t-mobile/tello's network as far as i can tell.

i'll be posting more as i use this phone more throughout the day, probably.

update: it wiped my face unlock data. woohoo!

using heytap app market globally

something i've been curious about for a bit is the oppo heytap app market. it's part of oppo cloud/heytap services, and is documented as being china-only. though, in recent times it has expanded to a limited extent. notably, to india.

the standard APK you'll find when looking for "heytap app market APK" on google or wherever will typically be said chinese version. shockingly, the app is in chinese.

the version for india, however, is primarily in english. you can discern an india version by checking if the version name is suffixed with _IN. off the bat, it looks mostly like the chinese version.

thing is, it shouldn't.

plenty of bugs are here. search doesn't work, many apps that should be on app market lead to 404 errors (even some featured apps do!) and an abnormally small selection of featured apps in some tabs.

the reason for this is actually quite simple, and it's that your phone is just set to the wrong region. you must have your phone's entire region set to india...which is a shitty requirement and considering you're changing a global, system-wide setting, is bound to cause random, weird issues. your date format is changed, forced to 24-hr (though you can change this back) and some apps prompt to change the region.

you can't even correct the date format. clearly, this is a terrible solution.

though it's not all terrible. once you switch regions, the whole app basically changes.

here's the IN region layout.

search works, and the whole layout changes too. you can access the full library too.

perhaps i might crack open the APK and try to patch it to always request IN region from the server, but knowing oppo, they probably have some crappy anti-tamper software inside this thing to prevent exactly what i'm trying to do.

or maybe they don't, sometimes they lazy out in random places.

pixel 7(a/pro) supports 32 bit ABI apps

for some ungodly reason, the tensor G2 chip used in pixel devices shipped out around 2022-2023 include a bizarre manual block of armeabi and armeabi-v7a arch executables. pm will refuse to install them, and zygote itself does not support running them.

so why?

frankly, i don't know. preparation for armv9-a? maybe.

the problem with this is the simple fact that the tensor G2 isn't even armv9-a. it's arm64=v8a like most chips had been for the preceding 7-ish years. in consequence, the 32-bit executable block is entirely artificial. the chip can run 32-bit arm instructions natively. google just sucks.

if you want to enable it, check this xda thread (or this github repo if xda is dead) for how. it's basically a patched up version of magisk that fixes up your vendor prop.

inner machinations

the workings from what i read are quite simple. according to this diff, it just checks /vendor/build.prop to see if the in-use zygote (ro.zygote) is zygote64 (64-bit only zygote) and swaps it to zygote64_32. then it checks the if list of compatible ABIs (ro.vendor.product.cpu.abilist) only contains arm64-v8a, then changes it to arm64-v8a,armeabi-v7a,armeabi. lastly, it checks for a blank abilist32 (ro.vendor.product.cpu.abilist32) and sets it to armeabi-v7a,armeabi.

in short, these changes are made:

ro.zygote=zygote64_32

ro.vendor.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi

ro.vendor.product.cpu.abilist32=armeabi-v7a,armeabi


theoretically, one could patch their vendor.img manually and forgo the janky magisk method, and that should enable a way enable 32-bit ABIs on newer android versions, as the magisk version is quite old and unmaintained.

of course, you could just fork magisk and add the necessary patches again....but why?