A big win for Android interoperability
openhomefoundation.org
openhomefoundation.org
You could claim that's not an android problem but if you do I don't think you've ever had to explain to people your phone doesn't have a Google Play store.
define open wallet then
I don't really care, as I'm protected from fraud by the card issuer and regulations in my country.
> Having my phone stolen is pretty much another level of attack.
Stealing a wallet or a phone seems just about the same level of difficulty.
And you can trick an iPhone into believing you're a transit terminal and charge arbitrary amounts to real credit cards, without unlocking the phone. (And Apple thinks this is a feature.) The attack requires specialized hardware and physical access, but if you've stolen the phone, that's fine.
(Yes, I know, this article is about Android. But most people where I live have iPhones, even if I don't.)
I get that you might want one if you are a tech maximalist with a single focus. But that doesn't mean you should stop carrying your card.
And to add to payments, the store loyalty apps are the worst... Lidl over here has an app only (no physical loyalty card), and they should be hanged for developing that... first of all, you're waiting in line while a grandma takes her phone out of her purse, then unlock it, and of course android is not satisfied with her fingerprint right then but also wants a pin... then all apps, then scroll down to L, find LidlPlus app, tap on it... QR code? Nope, not yet! First you get a daily coupon wheel of fortune, tap, wait for it to spin, see what your award is... and if it's something that she just bought, she has to manually activate that coupon in the menu (again, tap, find, tap, tap back), and then click the card button to get the qr code to scan... it's literally minutes sometimes of just waiting, instead of scanning a simple qr code on a plastic card pulled from the wallet.
We even had one of our telcos break down (full internet loss, country wide), POS terminals not working at all, and there are actually people with zero cash with them, not even like 50 euros (for just-in-case (like this))... and then you have to wait for them to turn around, take their stuff back and go home hungry.
Do you guys not have wallets with card slots?
That people trade anything for even just perceived convenience? That isn't news either, but it does explain a lot of the sad state of affairs we are struggling with today.
You live in a pretty weird bubble. (And I live in San Francisco, so I know about weird bubbles.)
That's from a year ago, I'm sure it's only grown since.
I think it's you who's in a bubble, my friend.
I assume the same must exist for euros.
I would never use a physical card with NFC anyway because it is both inconvenient (have to enter PIN every 5 transactions) and insecure (for transactions without PIN there's no verification layer), whereas on my phone I have to unlock it for every transaction no matter how small, and doing so is a small matter of pressing my finger on the fingerprint reader.
I'm as anti-capitalist as they come but this is kind of a lost fight in my mind because if not Google - then Visa/Mastercard and the bank itself will know every transaction I make anyway.
I’m talking about in-person payments though. It would be so easy to implement QR payments backed by the existing SEPA Instant rails. Many bank apps already understand EPC QR codes (usually found on invoices), so shops could just show these to accept payment. In case your bank doesn’t support SEPA Instant, you could show the cashier the receipt in your bank app, which, well, horribly insecure, but probably fine for low-stakes cases like grocery shopping (you don’t want to be banned from your grocery store chain for forging a 35 € payment).
What a single hacker writes is on the other hand just what he wrote.
You can sidestep this however by not dealing with cards. I’d look into various QR payment schemes.
Anyway, looking forward to the widespread introduction of Wero. Maybe there will be some options for third party roms in the name of digital soveranity. Seems like they want to make the EUDI wallet for digital documents no-google capable for that reason at least.
A first step would be requiring Google to attest all devices that have a locked bootloader, verified boot, signed with non-public keys, and have a recent Android version and patch level.
IMO they should also boot anything older than Android 16 and behind more than 1-2 ASBs, if security is the real reason to have Play Integrity remote attestation.
Source? I thought it was free for OEMs?
Seems to be only in the EU (because they're being forced to), and some other sources say google is offsetting the fee through revenue sharing back to the OEMs. In any case the original claim of "the purpose of remote attestation is to force people to buy devices that pay Google license fees" is questionable given that google had to be forced into charging money for it.
https://www.theverge.com/2018/10/19/17999366/google-eu-andro...
The only reason why we don’t have them is Google / Apple duopoly.
Banks letting an open source project run transactions through them... that's... hilarious.
I think the point of GrapheneOS is being as secure as possible first and within those parameters give people the choice how much of Google they want. They have implemented sandboxed Google Play Services for a reason. Many people need Play Services for practical reasons (e.g. because they need to run apps that require it), so let's then run it in the most secure/private way possible - make it a sandboxed app, allowing users to decide whether to install it or not and if they choose to, that they can assign/revoke permissions like any other Android app.
- They might want privacy from Google. Using Google Pay probably doesn't make much sense.
- Security protection against Google. Google can remotely brick devices with unsandboxed Play Services. After blocking of ICC officials and all the Greenland threats, it's not odd that some European citizens would like to block this Google/US government attack vector.
- They want a clean phone without all kinds of crap like Gemini preinstalled.
- They want to reduce dependence on big tech/Google product in general.
In cases 2-4, using Google Pay with sandboxed Google Play services may be an acceptable compromise for convenience.
When you find battery life randomly tanks for a few days, despite not changing anything in your life, it's always Google Play Services that end up being the culprit
No.
I hate AI writing, so I never use AI for writing. Randomly throwing in accusations in discussions sucks. I don't think my comment had any of the hallmarks of AI writing either, unless bulleted lists are also not-done these days.
I guess I should be happy that people don't recognize me as a non-native speaker anymore?
I don't follow. If you mean against fraudulent spending phone based tap to pay is probably the most secure. It demands user authentication (biometric or code) for any transaction so there's no real way to trigger a fraudulent spend without the user knowing. Pretty much any other system allows for at least some amount of unauthorized spending if it's stolen.
If you just mean it's less private than I don't really know that it's terribly different than using a card. Especially if the ecosystem were open and you could choose your payment provider and not just have to use Google/apple.
If anything, this attack is a benefit of mobile payments, where you need a second device to perform the attack with, and the user to use verify themselves for the payment to go through.
Probably not but you’re doing a bad job explaining what wanting to de-google your phone has to do with the choice of wireless payment methods.
It’s in the name, “de-googling”, not “de-attack-vectoring”. People want to break away from Google specifically. They’ll still use tap to pay because it’s convenient, secure enough, at least as private as any card/bank payment, and ideally not Google, which was what people de-googling want.
Or using a (smart)phone, right? No need to go to extremes, cutting Google specifically is the win because they centralize the “spying”, not cutting the technology.
You’re stretching this for no good reason and trying to find a connection that doesn’t exist just to save your argument.
But more than that I want to have a choice.
Some people just want a phone without the duopoly and nothing else.
Also de-googling isn’t the point of GrapheneOS.
You don't live life only having privacy or not having privacy. You fall somewhere in the middle. You can shift your overall privacy posture up if you de-google, even one service at a time.
Uninstalling Google Maps, whilst still using Gmail has privacy benefits. Each step improves your privacy. Some opt for convenience over privacy, you can pick and choose services to use whilst still retaining decent privacy.
Google Wallet currently will not run on a fully updated grapheneOS.
Specifically it complains:
"Your device doesn't meet tap to pay security standards. It may be rooted or running uncertified software."
Which is fair. But something that actually works would be nice. I can keep extremely tight control on the NFC stack by toggling NFC with a quick access icon.
Not something I use very often, but not getting locked out of specific, not all, financial rails is one of those things that feels like it rubs up against the perpetual friction that the US founders, framers, whatever; didn't enshrine economic freedom in the same way as speech.
And maybe that's a libertarian fantasy. Idk. Seems worth thinking about for five seconds tho.
Bringing it back to reality. There are an incredible number of issues with trying to set up some kind of a competing service to Google Wallet to the extent that you might as well just go start a bank. And companies like simple have tried that and ended up bought by other banks at the end of it. And they weren't even trying to do anything other than offer people a banking app that wasn't total crap back in the day.
So realistically Google wallet or anything like that is not something I expect to use on a graphene OS phone until the graphene OS Motorola device comes out in the next few years. And that is entirely speculation that services like Google Wallet might be able to work on that device. But honestly it's the only real hope I personally hold for getting access to Modern payment systems on a secure device.
Android already supports this, and has supported this for over a decade. The restriction here is on the side of the finance ecosystem. Everyone has congregated on doing Apple/Google Pay because it's cheap and easy to maintain compared to the alternative. Cards companies and banks make deals with Google, just like they do with companies like Apple, Samsung, and Garmin.
Any fintech startup with serious backing can create an Android app that works on any ROM you can imagine. I don't think you'd have an easy time finding investors for this with how much money you need to partake in the ecosystem, but the API is ready for you to implement.
That should also tell you that almost any open source / non-profit solution is doomed to fail due to costs. What could work is if, just like the UnifiedAttestation initiative has commercial backing, Wero is expanded to also have its own NFC payment stack. The EU already forced Apple to open up NFC, so it is possible to do it for both iOS and Android.
https://glenbrook.com/payments_news/russias-mir-domestic-pay...
Just an application which emulates the card over NFC. No need to Google Play Services. It's been this way for ≈10 years I guess.
Some European banks including mine offer NFC payments via their app as well. You don't need Google services.
NAB here in Australia did previously as well, but then they stopped doing that in 2022.
https://www.zdnet.com/finance/banking/nab-waves-goodbye-to-n...
Big if true. I guess the main problem is, would the banks from all over the world join in?
Fidesmo (https://fidesmo.com/consumer/fidesmo-pay/) has managed to sidestep this by integrating with Curve (https://www.curve.com/), which issues their own card and then charges your bank’s card from their end when you pay with theirs (tokenized and emulated by Fidesmo).
(Fidesmo also integrates with a whole bunch of banks directly, though mainly EU.)
Bonus points if you require the primary UI (window manager in the language of the ancients) to be an installable app.
My favorites:
> 6. Structured on-device integration
> AI services will be able to easily interact with other apps installed on the device and perform tasks on behalf of the user within those apps, for tasks that the apps and the user have chosen to make available to AI services. These tasks include “send a message”, “create a note”, “schedule a meeting”. This includes access to certain Google apps (i.e.Gmail, Calendar, Drive, Docs, Maps, YouTube, Messages and Phone) that Alphabet will make available through operating system-level integration channels.
> [...]
> For instance, Android implements structured on-device integration through App Functions, which developers can enable for their apps, and which can be accessed by AI services without being reserved anymore for Google services, such as Google Assistant or Gemini.
> 7. Screen automation
> AI services will be able to automate multi-step tasks within apps, on behalf of the user upon their consent. They will do so by imitating user behaviour in a separate virtual window, which makes it possible for the assistant to complete the task in the background, while the user can do something else. [...]
> Android implements screen automation via Computer Control, which can automatically access apps, and which is currently reserved for Google’s services, such as Gemini.
> 9. System-level on-device models
> AI services will be able to call on existing on-device models (“ODMs”), including the Gemini Nano ODMs, that are part of the DMA designated operating system, already preinstalled on Android devices and already made accessible to third parties. As a result of the measures, third-party AI services will have guarantees of equal access (for example, in terms of performance) to ODMs, as Google’s services. [...]
> 10. On-device model implementation
> Third parties will be able to install, run and use on-device models (ODMs) under the same hardware‑resource and background‑execution conditions that Google’s own models enjoy, and will allow their ODMs to be shared centrally with other apps. [...]
Anyway, the actual decision text: https://ec.europa.eu/competition/digital_markets_act/cases/2...
Edit: reading that document, I understand now why that press release, as well as the submission above, doesn't get further than a handful noteworthy properties and that even those partially seem like dependencies of each other: that's all it is. It's all about running code on a device activated by a hotword and the access such that it can actually be used (access to the NPU, ability to run in the background, ability to start phone calls, access to sensors, ability to display things on the screen...)
The core issue is not "Google not allowing a feature", it's that small businesses cannot buy phones, install a patched version of Android without a restriction and sell them to make money.
Until this problem is solved, everything else is palliative.
DMCA and other anti-circumvention regulations.
Some of the ones that seem unlockable are actually not unlockable in practice. Like Xiaomi which provides an unlock option that doesn't work unless you work for Xiaomi.
Hopefully the hardware vendor GrapheneOS is working with can add a second product line to the list.
Pardon my ignorance; but why would Android need to be patched? Is it because it wouldn't run on the phone hardware otherwise?
Because those 11 features mentioned in the OP post need to be unlocked.
Please stop parroting surveillance tech company's narratives.
To what end? Do you think that kind of approach convinces anyone?
There is no "fake android," either. Your whole argument is based on two false premises.
Besides, depending on the actual OSI license, you can definitely have bootlegs if you really care to argue.
A bootleg does not need to be exploited commercially. It can just be counterfeit.
I am not insulting you. I am telling you that you are being overly pedantic while being wrong at the same time. You might find this difficult to accept but I'm just calling it.
> I said bootleg Android didnt I?
And you're still doing it. Just let it go. It doesn't matter, your argument is wrong either way.
Also, please stop insulting me.
If your worry is about phone-home, no need to mention Android specifically. This happens with all off the shelf phones. Point is about a phone that has an OS that looks like what you would expect and just doesn't do what you expect. Obviously you didn't understand what I had written so I had to call you on that. You may feel insulted, does not mean that I am insulting you.
Anyway, just so that it is clear. Probably should end the conversation here so no one feels insulted any further.
No, my first comment is this:
> Everyone who buys an Android phone. This is about the opposite, an option to buy a phone that does not do that.
It doesn't say anything about "bootleg."
> Obviously you didn't understand what I had written so I had to call you on that
Again, please stop insulting me.
> You may feel insulted, does not mean that I am insulting you.
Look, I want to give you the benefit of the doubt, but it's really difficult. Do you genuinely not understand that the following things you said are insulting?
"So pedantic, you must be fun at parties."
"you are being overly pedantic while being wrong at the same time. You might find this difficult to accept but I'm just calling it."
I do understand that some people lack social awareness and therefore don't understand when they are being insulting, so it's possible that you genuinely do not realize how you come across. I am telling you now, though, that saying things like these is, in fact, insulting, regardless of your intent. So if you genuinely did not intend to insult me, I hope you will now stop writing stuff like that.
What you do not seem to understand is that with a normal Android distribution, you expect a phone home tied to the manufacturer of your phone.
Matter fact, as I pointed to you but you conveniently ignored, it does not have to be an 'Android' phone. It is the same for Apple and their iphones and pretty much all off the shelf phones. Not need to single out Android if your point is not about the fact that I said 'bootleg' Android...
With a bootleg Android, you forego any security, beyond the phone home. ANd you wouldn't even find someone to speak to about it. What is so difficult to understand?
I don't think it's high volume, I think this is done by some of the microg folks.
But OEMs probably do everything in their power to make this business model unviable or at least not scale.
When it comes to running patched operating systems, Google's phones are pretty much the only ones that provide a decent option for running secure and user-controlled firmware. It's every other vendor, from Apple to Xiaomi, that's preventing people from doing so.
That said, there are a few companies out there that will happily put your brand and your firmware on their hardware. That's how the Trump Phone was made, the biggest example of this practice in the west. Other utility brands have been releasing cheap crap branded phones for years (like the Gigaset smartphone). You'll need money upfront and a decent minimum order quantity, but getting phones with firmware you control straight from the factory is still an option.
Obviously the Google Play features being available only to Google are a problem, and it's good that the EU is forcing Google to cut the crap, but Google's restrictions aren't the reason companies aren't running custom ROMs. It's pretty much everyone but Google that's at fault for that, from vendors restricting user freedom to app developers restricting their apps to Google Play certified devices only.
The future lies in a large, local-friendly ecosystem and the hardware to support it.
Gate keeping software makes even less sense nowadays.
The competition is on compute offering. Cheaper, faster, at scale. They can have a competitive advantage over incumbents if they stay smart.
It is not necessarily a competitive advantage, because Apple needs to do the same (which is why they aren't releasing the new iOS 27 Siri, etc. in the EU).
Apple and Google just took different approaches: Google just released their stuff in violation of the DMA and had the EU come at them. Apple chose to be in compliance before before releasing their assistant updates, though they tried to lobby the EC in favor of releasing now with the promise of adding interoperability in N months.
I am completely in favor of this. But for Google/Apple the best outcome giving their own assistance preferential treatment. More subscription income.
Interoperability is the key to breaking out of walled gardens and owning your own data and digital self.
This is a big win but google will fight back it seems instead of embracing interoperability.
It may seem trivial but using a small DSP running a tiny model to provide a battery efficient always on wake up call for home AI is huge.
As a carer for elders who rely on AI to use modern devices in the face of their difficulty keeping up with interface changes this bodes well.
Gatekeeping AI and the future with hidden features is straight out of the bad old days of M$’s embrace, extend and extinguish.
I embraced AI to let my elders control their home and they love being in control but are constantly frustrated with UI changes and often find themselves stuck unable to call me with ‘Alexa call Daniel’ which provides them with hope if they wake stuck in a nightmare.
Come on google, please don’t be evil embrace interoperability and the open source community.
Well done Eff, Cory Doctorow and the Pirate parties of Europe for this small win
If you run a custom ROM, you can sign your own RCS app and have no such restrictions, of course. The same is true for devices with root access. There's nothing preventing anyone from writing a fully featured RCS client or library for custom ROMs, except maybe carriers filtering out unofficial ROMs, but those are a SIM card swap away. Nobody seems to have started working on an RCS app for those platforms yet. There are a few open source libraries out there, but they don't see much activity, and none of them implement the full RCS suite (which includes video calling and even exchanging money).
When people complain about RCS being closed off, most of them don't care about the RCS protocol. They want Google's libraries to handle all the hard work for them and provide an API to interact with without having to implement the carrier protocol side. RCS is already open, but they want Google Messages to be open, not RCS.
However, the EU's laws regarding gatekeepers require that a significant amount of people actually use the supposedly gatekept platform. Very few people within the EU use RCS. I don't think RCS is even close to being relevant for the EU's gatekeeper regulations. The only people talking about RCS on the European market are companies trying to peddle their RCS marketing spam delivery mechanism to other companies.
If the USA would adopt similar laws, the situation would probably be different. Don't expect the EU to care about gatekeepers in a market consumers aren't interested in.
The AOSP messaging app is barebones to say the least, and has been abandoned since the day Google announced Google Messages and its predecessors. Back when that app was still relevant, RCS practically didn't exist.
RCS is not as simple as SMS. You need access to the SIP/RTSP/RTP layer to do video calling, for instance. RCS registration is tied directly to IMS registration, it was never designed to have multiple apps use the protocol at the same time; it does support multi-device setups, as long as all partipants run compatible software. Break that, and you break basic message reception.
Skipping features that go beyond basic messaging entirely, you could probably have some limited RCS support if Google were to take care of all of the internals. You would still need someone to do regular maintenance, like updating protocols to support things like gRPC transports (which landed this month), taking care of the end-to-end encryption, and whatever else comes up in the future. End-to-end encryption in RCS has been in the spec for maybe a year and a half, Android 14 and lower would not be able to use it at all, and Android 15 would miss out on Apple-compatibility as well. Not sure how you would deal with the payment exchange API in such a system, that would need some carrier/bank-run verification scheme.
AOSP's RCS implementation (https://source.android.com/docs/core/connect/ims-single-regi...) was never used by Android's messenger, it only provides very basic functionality: it exists because it has to for basic IMS operations to work, but Google never really bothered with RCS until very recently, long after they stopped maintaining their SMS app.
One could ask the same of other messengers: why can I not access Signal's message database? Why can I not enumerate emails, or query for browsers' search histories? All are built on open technologies, after all.
From an openness perspective this is excellent. Technically it seems challenging with a DSP designed to detect a single thing using as little power as possible. Currently this balances doing as little work as possible to detect plausible utterances of the wake-word on the DSP while minimizing the costs of spurious wake-ups on the CPU. At the very least multiple wake-words seems to need the DSP to do more work and wake up the CPU more often.
It sounds reasonable to apply the same logic to all vendors with similar market power, though. Perhaps this opens the door for an accelerated procedure against Apple as well
It is also pretty jarring to see the EU talk a lot about sovereignty, but then further entrenching the Android/iOS duopoly by baking remote attestation into the EUDI reference wallet (and copied into the national wallets), effectively shutting out alternative systems yet again.
Yes, I know that the EU consists of a lot of bodies and sometimes the right hand doesn't know what the left hand does. But man, sometimes I wish there was a stronger single, long-term vision. Somehow they seem to have forgotten about January this year (Greenland threats) and that as long as we fully depend on Android/iOS, etc. the US could shut down pretty much all modern communication infra. But instead of solving these vulnerabilities now and pouring money into alternatives, we (as the EU) drag ourselves down into battles of just how much we can do on the terrain of some feudal overlords.
It seems like there is a short window where we still have AOSP systems that could be workable for the large population (outside remote attestation, pretty much all apps run on GrapheneOS, microG, etc.) and Google's strong arming through developer verification and remote attestation could still be put back in the box. But the EC does nada, nothing (presumably).
That has benefits - you do not have to trust Motorola not to ship stuff that you wouldn't want in the image. They are pristine images that the GrapheneOS project provides. But it also probably doesn't get Motorola in hot water with Google, since they partially do the same as Google does (provide phones with unlocked bootloaders) and what Google used to do (open drivers, device trees, etc.). Plus there are other OEMs that have similar partnerships with other projects (e.g. Fairphone).
into accepting their chain of trust
It's GrapheneOS who will sign the images, not Motorola.
Speaking of Europe, Motorola is probably not big enough here to strong-arm parties. Besides that, I don't think they will do that, since they have to stay in good graces with Google for distributing GMS Android.
I think for Motorola, there are three wins: 1. GrapheneOS has hundreds of thousands of users now, for a smaller OEM capturing some of that market is a significant addition; 2. they want to have a security-focused offering; GrapheneOS can provide that; and 3. they probably want to strengthen their position towards Google. Samsung has their own app store, device finding ecosystem, etc., this tells Google - if you take too much power, we can go our own way. If the Motorola-GrapheneOS experiment is successful, this could provide a similar contingency plan that might hold Google from trying to reign in OEMs too much. This is a real risk for Google - Pixel is so small in terms of marketshare that if, say Samsung, would go on its own, Google Android is pretty much dead.
At any rate, I think Motorola-GrapheneOS can have more of an indirect effect. I think Play Integrity remote attestation will fall if GrapheneOS can quickly get so many users that they become a force to reckon with. In the past, it helped when GrapheneOS users e-mailed an app developer that switched to strong Play Integrity. This will be much more powerful if the GrapheneOS user base grows 10x and more growth is probably possible if there are non-Google devices (especially because part of the potential user base does not want to give a cent to Google).
Getting the EU to ban Play Integrity as-is probably has a much larger chance of succeeding though. This is why I always recommend people to file a DMA complaint/contact the DMA team when some app gets blocked on alternative ROMs due to Play Integrity. The DMA team needs to see/feel that this affects a lot of real people.
Unlikely to happen, it's just not how they operate. Instead they will create a government registry where any legal entity can register their integrity attestation keys, with oversight by a bureaucracy in a process that takes 6 months and €100,000. Apps will be required to use the registry but still allowed to block attestations they don't like, and any attestation key that leaks into open circulation (such as FOSS) will be blacklisted in the registry because it no longer attests anything.
That wouldn't be great, but at the same time an improvement over the current situation.
attestation key that leaks into open circulation (such as FOSS) will be blacklisted in the registry because it no longer attests anything
Which makes sense if remote attestation is what you want.
Source-available isn't quite the same as having the software freedoms (use, study, modify, share) where you can modify the code or inspect what the various third-party apps are doing on your device. I can currently look into /data/data/any_app and modify preferences, view what telemetry is queued up, remove gigabytes of cache files... all that goes away with a GrapheneOS installation that passes attestation. They want to appear legitimate to app vendors and so comply with Google's rules about what data is accessible to users; otherwise, they'd never convince anyone to add their attestation keys to the allowlist. You need to be on a closed device before those vendors put you on the allow list (and you probably need to sell at least a million devices before they bother to consider you). The concept of attesting your phone is fundamentally antithetical to open source
also they should not abandon Nokia back then
China literally backwater in 1970s, now they have some of the biggest software tech itw
there is no excuse
so European Union didn't exist ??? this is literally just an excuse
like wtf is this answer, its like y'all give up from starting point
(Yes, I know banking apps can have their own tap-to-pay implementation on Android, but they all standardized on Google Pay because it's less work for them.)
It's up to third party app developers to choose what library to use, of course. A court case between the EU and Google isn't going to chance anything about the verification steps apps like Netflix or your bank might use, that will have to be a separate case.
feel free to keep your why did you have Instagram on your graphene OS phone to yourself. I know. I know. I know. I know. XD
and a little message when you tap on those notifications is exactly what the parent commenter stated encouraging users to contact app developers so that they can use basic integrity attestation and allow their apps to work on graphene OS.
and some apps do work and use the integrity API. maybe a little too much in my opinion. chatgpt I'm looking at you. my local credit Union's banking app doesn't even bother with the integrity API and they updated their tech stack recently which included app redevelopment.