I fully agree with it. But I think Google also understands that the platform is unatractive for businesses. In my case I just don't do Android app because I know it is easy to just take and hack. It is not the case on iPhone. And my app is one time payment so the ability to just copy out the APK leaves me not doing an app at all...

▲

Jean-Papoulos 3 hours ago | parent | next [-]

The people that go through the trouble of installing apks from random websites to not pay $1 are in the minority. What's more, most of them wouldn't pay that dollar if they couldn't find the cracked apk. So the only thing you're realistically doing is cutting yourself off of a huge market. Convenience sells, the Play Store does that

	▲	dainiusse 3 hours ago \| parent [-]
		$1 - most probably. What about $20?

▲

_imnothere 5 hours ago | parent | prev | next [-]

> I know it is easy to just take and hack

No you don't, otherwise we wouldn't have banking apps on it.

▲

dainiusse 3 hours ago | parent | next [-]

It is a bit different. My app doesn't rely on 3rd party services at all. It just provides functionality. It is not about breaking into someones account.

I just know that the app can just be cracked - there are plenty of sites that do that for android. Because you can't just load your app on iOS - this is just not possible (well perhaps there are a few percent of some jailbroken iPhones, but that is neglibile).

On Android though, you can soon see such app stolen and on some of the apk warez sites. It just breaks the model.

	▲	stevefan1999 3 hours ago \| parent \| next [-]
		> On Android though, you can soon see such app stolen and on some of the apk warez sites. It just breaks the model. Think about Windows and software privacy
	▲	kmeisthax 2 hours ago \| parent \| prev \| next [-]
		The only difference between iOS and Android when it comes to loading code onto your device is that, on iOS: - You have to setup a developer account with Apple first, and dev-signed apps can only be installed onto specific provisioned devices only[0] - The free tier of that developer account is inconvenient for actually using dev-signed apps as a daily-driver, and won't let you use certain entitlements - Apple's dev tooling is designed to make it feel like you can only sign code you're compiling yourself On the surface level, this might seem like a big difference, because Android has a command that lets you load arbitrary APKs with no particular fanfare or ceremony, while Apple's dev signer is buried inside of a compiler/IDE suite. But people have built tools to make it easy to take an arbitrary .ipa, sign it using your dev account, and resign it once the free tier's 7 day limit expires. Of course, this still requires you actually go and obtain an .ipa of the app you want to use, and Apple distributes App Store[1] app binaries[2] encrypted. That part requires actually having a jailbroken device to dump the app binary with. But once the app is cracked anyone can install it. If you want an actual "uncrackable" app you need to put a critical part of your app's workflow onto a server, and then have your app send an iOS DeviceCheck or Google Play Integrity attestation that the phone is running the actual App Store/Google Play version of your app. But that's also incredibly draconian behavior towards your customers as it basically forces your app to be always-online... which is why a disturbingly high number of games do this. [0] Yes, I know about Enterprise signing, but Apple specifically forbids distributing Enterprise-signed apps outside of your organization and those apps get revoked all the time. Signing with your own dev account is way more robust and that's what most iOS power users actually use. [1] I have no clue if FairPlay encryption applies to EU-DMA-compliance signed apps. [2] ONLY binaries - all your resources are unencrypted and can be downloaded off the App Store CDN and inspected by anyone. Code signing signatures do apply to resources, AFAIK
	▲	kotaKat 2 hours ago \| parent \| prev [-]
		> Because you can't just load your app on iOS - this is just not possible (well perhaps there are a few percent of some jailbroken iPhones, but that is neglibile). No, smart normies are sideloading with the 7-day limit and leveraging automation to have their pirated apps automatically re-sign and re-push. If you pay the $99 to Apple for a dev cert (or like $10 to a service that'll sell you a cert off someone's account), it'll even just sign out for the year for you. No screwing with Xcode or anything, just drag-drop-sign. Even gives you the options to patch the app out at resigning so you can do hacks and mods like the good old jailbreak days. https://sideloadly.io/

▲

graceful6800 4 hours ago | parent | prev [-]

Have you tried extracting, decompiling, and modifying someone else's app?

It wasn't hard before LLMs and it's nearly trivial now.

▲

skinfaxi 4 hours ago | parent | next [-]

Is that not possible with ios applications?

▲

Xirdus 4 hours ago | parent [-]

You can't sideload iOS applications. Meaning there's no point to doing any of the listed things.

▲

stevefan1999 3 hours ago | parent | next [-]

You technically can sideload. For 7 days or on TestFlight

	▲	fsflover 2 hours ago \| parent [-]
		This is not a practical way for installing apps though.

▲

drdexebtjl 3 hours ago | parent | prev [-]

Of course you can. How do you think developers test their apps?

	▲	Xirdus 29 minutes ago \| parent \| next [-]
		Never did iOS development. I always assumed it requires active USB connection with a dev machine or an emulator.
	▲	actionfromafar 3 hours ago \| parent \| prev [-]
		Normal people can't. I'd bet more people run jailbroken than bothering with developer-mode sideload.

▲

hparadiz 4 hours ago | parent | prev [-]

The crypographic flow that allows payments to work is straight up pub/priv key encryption with one time use tokens. It's not something you can hack. As soon you see the token it's already been used and thrown away. So whatever nonsense about decompiling literally doesn't matter.

▲

jfyi 4 hours ago | parent | next [-]

So your professional opinion is that the attack surface of mobile banking apps is limited to tokenized payments? Honestly, I'd be appalled if tokens were routed through my banking app. There is no reason the local client needs that data.

▲

hparadiz 3 hours ago | parent [-]

My professional opinion is that APKs can be de-compiled regardless and that has nothing to do with tokenized payments themselves which are like you said handled through server-server communications at the payment processor level. Your phone simply sends a one time use token to authorize the transaction.

▲

jfyi 3 hours ago | parent [-]

You were the one that brought up payments though. Nobody else specified. They just said it could be hacked, which you seem to agree with.

▲

hparadiz 3 hours ago | parent [-]

I don't agree that your example makes sense. Don't feel like writing a wall of text. Zero justification for a locked down system.

	▲	jfyi 2 hours ago \| parent [-]
		What exactly was my example? You agreed with me already. Kind of odd to flip around now. > which are like you said handled Also, I corrected your misstatement about payments. They have absolutely nothing to do with decomp, and certainly can't be used to dismiss the entire attack surface of a mobile banking app. Your example is complete nonsense. You are really digging a hole here.

▲

pixard 4 hours ago | parent | prev | next [-]

He said his app is a one time payment. Presumably there isn’t a backend and he relies on App Store purchases. I know, it’s shocking an app could just be an actual application rather than a web view.

▲

skinfaxi 4 hours ago | parent | prev [-]

You can patch out the payment checks if you can decompile it

▲

hparadiz 4 hours ago | parent [-]

The payment doesn't happen on the device. It happens at the VISA/Mastercard/AMEX level. So "the app" should be doing the validation upstream on the server side and simply reporting yes/no to the app. If you hack the yes/no okay but most payments are for physical things IRL so the payment gateway that is not on your phone is gonna be like ??? - in other words it's on the app not to trust a raw true/false signal and instead rely on server side checks. This is all irrelevant. I make regular massive purchases on my linux box where I can read the memory. It doesn't change anything.

	▲	skinfaxi 6 minutes ago \| parent [-]
		Ah I see you are focusing on apps that have some web component that would enable ongoing authorization. I was thinking about apps that offer a trial but you can upgrade with an in-app purchase and there is no ongoing service component.

▲

curt15 39 minutes ago | parent | prev | next [-]

Do you target macos or windows, which have always given users full control of software management?

▲

drdexebtjl an hour ago | parent | prev [-]

The fact that app piracy is more prevalent on Android has nothing to do with technical differences between iOS and Android side loading, and everything to do with the markets in which iPhones and Android phones are popular.