hckrnws

Won't folks prefer to use native system features (e.g. password protected apps or the "hidden" album in Photos app)?

Maybe, but does that mean this app doesn't deserve to exist on user's computers if they so choose? Not sure why Apple has a say in that just because they have a massive advantage over every other dev on their platform.

There can be different views on this, I guess.

Apple is known to like to exercise control and to keep their ecosystem closed (recall that Jobs was initially AGAINST the AppStore concept entirely, which was invented by someone else and now makes a ton of money for Apple).

Open systems with little control lead to a bazar like the various Linux distros with inconsistent-looking and buggy apps mixed with great apps - anything goes.

Imagine you are Apple and you want your AppStore to convey a professional and safe look and feel, you probably don't want 60,000 converter or image viewer app but a variety of tools, maybe 5-10 per category max, or it will be hard for users to navigate and tiring to explore.

> recall that Jobs was initially AGAINST the AppStore concept entirely…

Jobs was initially against allowing third-party native apps on the iPhone, but not App Store as a distribution mechanism. Once he relented on inviting ISVs to the profit party, the iTunes Store model was never in question.

I guess my disconnect is that the computer that a person owns isn't the same as a store that Apple runs and can carefully curate that runs on that computer. Combining those into one thing strikes me as dangerous, with not much upside. Everything you described can be true while allowing the user to use their computer how they want, it just doesn't make Apple as much money.

That, and how did Apple managed to approve an application that hides its true purpose like that?

The scariest part is probably the user-base ready to purchase such an App. The demo gif literally showcase "Jenn*Nud*.jpg" as an example..

Maybe I'm way out of touch, but does anyone over the 18 bother to hide their stash of pornography unless it's somehow illegal? I mean, be worried whether or not there's parental controls so the kids can't get to it, but to encrypt it?

1. Intimate photos of your SO rather than generic porn

2. A lot of people live in a more prudish/religious society than you may

>Intimate photos of your SO rather than generic porn

I file those under "never worth it to take the picture in the first place since it will eventually be exposed to the internet no matter how careful one is".

I feel like encrypting and hiding personal private photos/video would be the point, not so much downloaded porn.

Some people hide their porn from their partner / significant other; I don’t know why people rationalize that, but it’s common enough.

I mean, I don't like JPGs as much as the next guy, but idk that I'd call them scary

What's exactly wrong with that? We live in a society fully online, virt and nudes are literally a part of normal healthy communication

The Swift compiler is still the only compiler I know that times out.

Algorithmic complexity is such a large part of a fancy university education that I just don’t understand how they could come up with swifts feature set if they knew it would come back and royally bite them.

What an I missing? What is the backstory?

Im guessing:

The post Next Apple is entirely dependent on llvm. The hardware is tuned to its outputs. The devX is based on generating it.

Apple 15 years ago was getting worried people are not learning C in school anymore. They were learning python and ruby and js.

Swift exists as a way to market llvm as a tool chain to that market of programmers.

My views are informed by years of talking to Apple and build-for-Apple engineers.

The Swift devs drank the koolaid that Java's method of implementing generics using type erasure is bad, so they implemented Swift's generics by concrete specialization. Turns out that caused a lot of complexity in type lookup.

Interesting, I guess the language is now supervised by a committee which means there is no chance in hell it will be fixed.

C# can also do that - there's a general problem there with combinatorial explosion when you combine function overloading with generics and lambdas.

I like SwiftUI, reactive frameworks just make sense to me for UIs. It also interfaces with UIKit in a pretty nice way so you don’t have to commit to one or the other. I’m a newer iOS dev though, I’ve heard many complaints from more experienced devs.

I have encountered the infamous

> The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions

a lot. And it’s impossible to debug.

https://developer.apple.com/forums/thread/652691

that just means you have too many items together. break them up into smaller components or use something like a Group and that solves it. not a big mystery

The mystery is not why it happens, but how compiler tech can go backwards and still win.

Ps. I do like SwiftUI, just not the implementation.

We all know it’s just the Swift compiler getting confused.

In my cases I encountered this error in different scenarios in offset modifier, Strings, Colors.

I gave up on mobile app dev years ago.

To Apple, I'm not giving you $100 per year for four people to play my hobbyist games. Not to mention getting my account approved in the first place was such a horrible process. They can and will deny your app for random reasons. I don't know how any independent developer really wants to base their entire income around such madness .

What they want is multi-billion companies publishing content consumption apps, and occasionally some slightly smaller multi-million dollar companies might get some sales.

Google used to be cool, but now you need to have 20 or something people download the app to test it first. Which is easy to game if you have enough money ( or I guess you just go out and buy 20 devices yourself, a cheap Android device is going to run you $50 or so).

At least with Android I can point you to my git repository, feel free to download my free APK.

Look at the source code, the build process, install it if you'd like.

However, there's always light. WebGL is at the point where I can publish small games directly onto a web page. No one needs to download anything, and no one needs to worry about me doing something bad.

This article is about making money from the App Store, not distributing hobby projects. App Store is great for making money when that is your goal.

Some of the friction you mention is if anything a competitive advantage to those able to deliver quality work despite the challenges. I agree it's hostile to hobbyist development and early career learning.

I actually fully agree with sentiment. iOS is my side project which I've started to literally figure out, why AppStore became so bad. Old school AppStore was a Klondike of good indie apps, but not any more, and now I actually do know the answer. P.S. Being Apple developer made more for my desire to switch to Android, than anything else

I have a hard time taking people seriously who make such a huge deal out of the developer account pricing. A hundred bucks per year just isn't much money, I'm sorry, maybe it's my privilege talking, but if you're getting into iOS development you have, at base, one mac and one iDevice, if for NO other reason than development and testing of the app you want to make. The cheapest Mac available new is $600, and the cheapest iDevice is the iPad, for $349, or the iPhone SE, for $429. At minimum to get started as an iOS dev then requires an investment of just shy of a grand, and like, I don't particularly like that, but to then turn that around and be like "but this $99 per year subscription is ridiculous" is just... what!?

I don't consider myself a huge "project guy" either but I do tinker, and I absolutely CRUSH $100 per MONTH in terms of buying shit to fiddle with, from Raspberry Pi's to 3D printer parts, to new PC peripherals I wanna try, etc. etc. I struggle to conceive of someone in this space to whom $99/year for an Apple dev account is just this unbearable outlay.

A huge number of developers started in HTMl/CSS/JS because it was a super-low barrier to entry.

I also know a huge number of professional developers that started off as teenagers tinkering with Linux. They started with Linux because the hurdle was so low. No accounts, no fees. Download an ISO and burn it.

These platforms are hurting themselves long term by increasing the barrier to entry.

I'm not going to spend a second on the Apple/Android platform if I need to fork out money/account to try it out (even if I can afford it).

My problem is that its an annual cost. When I dabbled in Android development, I think I paid a one-time fee of $25. That's a cost I can swallow for someone who wants to release apps for free. If I have to pay $100 a year, I need to make that money back from my apps which means I probably need to make them subscription based. Which leads us to the world we live in today.

And that's Apple's goal, isn't it? Make you do enough recurring work and add enough recurring cost to get you to add subscription pricing to your app, that's the most profitable for them. Make you constantly rebuild your app with the latest iOS sdk in their IDE, on their OS, on their hardware, all in the name of security.

>If I have to pay $100 a year, I need to make that money back from my apps

Why do you feel you need to make it back? I can't think of many pastimes that cost that little.

Programming is a job, not a pasttime. If you enjoy doing your job, so be it, but you are trivializing this to an offensive extent.

It sounds like it is a pastime for the GP.

If it wasn’t then $100 is trivial for a business.

1) You're still overgeneralizing 2) If $100 was actually trivial for a business then Apple wouldn't demand it.

>1) You're still overgeneralizing

Do you think the OP is not doing this as a pastime? There is nothing in their statement to indicate anything but.

>2) If $100 was actually trivial for a business then Apple wouldn't demand it.

I'm not sure how you can make that leap.

"But you pay for other things" is not a good excuse. It's not that the price is unbearable--it's that it exists at all. I'd also complain if the price was $10/yr or $1/yr. It's the principle. I'm not going to pay for a row in a database that doesn't cost the company anything, without grumbling about it.

All right, I'll give you an example. I made a small game about 4 years ago for iPhones, maybe 30 people downloaded it. It works fine, it's just a small game.

To prevent apple from just taking it down I have to pay $100 per year, meaning even if I don't actively develop apps anymore, I'm just wasting money.

Now if I wanted to play the Apple dance every 6 months and hope they let me actually publish my games, I got a lot of pushback with my first project, then I guess it would be worth it.

> I'm just wasting money.

No, you're not. You're paying to have your game accessed by people. Do you also refuse to pay for web hosting on principle? Or some other WAN-addressable download location?

This is such a bizarrely specific entitlement.

But web hosting fees aren't arbitrary, they're based on the cost of distributing the program they've written. Apple can just declare that you have to rebuild your program for $100 a year plus the cost of all their other hardware to build it on, that's the difference.

Okay; in which case, your little game was probably free.

How much would you pay for hosting at this point? The cheapest Droplet on DigitalOcean will cost you $60 per year. Maybe you planned to have your game downloaded from Google Drive, but I’m with Apple on this one, a small fee prevents many bad actors.

Especially when 95% of iOS developers are comfortably in the top 10% of US salaries, and top 1% worldwide.

Itch.io is 100% free.

I'd be okay with it, if it was $100 per year while you're actively publishing new content. But just to keep old stuff up there is kind of steep

They don't want your unmaintained and unprofitable apps

Who is "they".

I'm not forcing anyone to download my game. But Apple refuses to allow any other market place ( in most of the world) , so unless I pay 100$ a year no one gets to play it on an iPhone.

It's not just the fee, it's the idea that Apple is the final decider of what anyone with an iPhone is allowed to run on devices they own.

I sorta understand this argument with game consoles, since the vast vast majority of console homebrew is just enabling piracy.

But that's not the case with a phone. I can't build a small app to learn and share it with my friends or teachers. I have to build something worthy of Apple, pay a 100$ annual fee and pray the Apple review team feels like being nice.

Apple

I don’t like their behavior either but I’m trying to help you make sense of it. They have a profit motive which corrupts

That’s the issue. It’s my phone. I want to run X on it, and the developer of X is willing to provide it. Why is Apple the arbiter in the middle of that exchange?

they are protecting their 15/30% of course

This. The $100 fee is inconsequential for Apple. It's there as a filter.

My apps only become unmaintained when Apple depreciates standard features. It's not my imperative to fix Apple's changes, they should be paying me to do that.

It is your imperative on their platform. Why are you protesting to me? It’s their policy and they have a profit motive leading to this. I don’t like it either!

I'm not protesting at all, I take a bit of delight in my apps that are no longer supported. Listening to iPhone owners lament "old-school" software and "lost media" is music to my ears. It's irony amped up to a palpable level.

My broader point is 1) it's not unmaintained until Apple says so and 2) it's only unprofitable once the App Store deems it is. Both of those are arbitrary decisions that justify nothing, even with profits as the context, which is why you are being downvoted.

What Apple "doesn't want" is people coming up with justifications against their arbitrary fees, case closed. No need to blame the developers and implicate yourself as a victim, that's an embarrassing dog-and-pony show that hasn't been fresh (let alone acknowledged by Apple) since like 2012.

The iOS/MacOS ecosystem is changing all the time, a decent amount of that time, they're good changes to be making. Sometimes they're arbitrary. Sometimes they're stupid. Either way, you know all of this before you publish anything there, so complaining after the fact that Apple is not sufficiently incentivizing you to maintain your code that runs on and is distributed by their operating systems is bizarre to me.

Yes, it's unmaintained, because you are not maintaining it. Should you maintain it? Your decision to make. However if they are not maintained then they are indeed unmaintained and will probably run into problems on newer versions of the aforementioned operating systems.

I personally like that Apple trims the fat and keeps things ship-shape. Yes, the cost to that is older apps don't work on newer Macs and phones. The benefit to that is MacOS and iOS are not saddled with god knows how much legacy code and features to make sure everything that ran on, for example, Windows 95 will also work on Windows 11 (with caveats). Both of these are fine design ethos to go with: Apple went one way, Microsoft another, and both directions have pros and cons accordingly.

> What Apple "doesn't want" is people coming up with justifications against their arbitrary fees, case closed.

Your personification of a corporation is bizarre too. Apple doesn't give a shit if you maintain your software or not. If you maintain it, it remains available. If you don't, it doesn't. This situation is fixed, and you know both outcomes.

Like I dunno, maybe it's just me, this logic doesn't hold up. It's akin to calling an engine needing oil changes arbitrary. Like, I guess? But you also knew that when you bought the thing.

> complaining after the fact that Apple is not sufficiently incentivizing you to maintain your code that runs on and is distributed by their operating systems is bizarre to me.

Let me tie things up a bit for you then. To repeat myself; I'm not complaining! I don't pay Apple a dime anymore, not for services nor hardware. I had a brief, happy stint as an iOS dev in my nascent, foolish years as a programmer and moved on. I find it hilarious that Apple can't do the bare minimum to support my software after I wrote it and paid them to publish it. It's part of the reason I refuse to build apps that aren't for the web anymore; native dev is for chumps. It is a literal waste of time.

> I personally like that Apple trims the fat and keeps things ship-shape.

Out of every commercial OS, Apple ships the most complex kernel and largest install size (on iOS and MacOS). If you think it's for "[trimming] the fat" then I struggle to see what fat they're cutting off. Most of the time, we're getting things depreciated like OpenCl and 32-bit libraries that users actually depended on to a certain degree, with no replacement besides proprietary alternatives. Seems like they're cutting off lean to me.

For chrissake, we're talking about a company that ships a mandatory 7gb AI model with every iOS install. Apple's "smart defaults" direction is just a load of cons, and I say that as someone that thinks Microsoft's model is imperfect too. But Microsoft doesn't get half the flak Apple does because they commit to third-party cooperation instead of treating it like an existential threat. They cooperate with Nvidia when Apple refuses to talk to them, they work with Khronos when Apple refuses to answer their letters, Microsoft seems to actually want their OS to compete. Clearly Apple wants to shelter theirs from competition.

> Your personification of a corporation is bizarre too.

I don't believe I characterized them at all. I said Apple's real excuse is not that they don't want depreciated or unprofitable apps (they can change that at-will by supporting old runtimes and allowing sideloading) but really that their defacto control over the iPhone is threatened. Unless you think copying over old dylibs and enabling sideloading is fundamentally impossible, I don't see how I've cast them in any particular light.

Nobody in this thread is foolish enough to say Apple has some outstanding commitment to queer values, quality apps or protecting user privacy. We've all watched that roof collapse over the past decade, we know money is king. My point in the last comment is that Apple's lack of transparency over which charges are necessary and which are arbitrary will be the end of them. It's a charade, and several countries (including the US) launched investigations to remediate it. Apple cannot persist with their current direction, and they refuse to admit they're wrong.

Yes it is all about protecting that 15/30%

Embarrassed to say, but I didn't know there are comments! I'll answer all of them asap and here is a second part https://safespace.is/blog/vilain-era-part-2 Sorry, guys, HN noob

> we decided to test a sharp pivot just before shutting it down: rename the app, change the concept from a photo vault to a converter disguise, and sell encryption as a feature.

I’m not really convinced that by just changing those you can suddenly get a lot of downloads.

Positioning/messaging matters a lot!

we didn't all core metrics fall 3 times

Really, the fact that Apple pushes swiftui as production ready is laughable. The framework is so ridden in bugs, does not play nicely with the other frameworks like photosui, and the language itself is incredibly bloated.

So many things wrong with this. Reminds me of the Objective-c vs Swift arguments from back in the day. The author mentions the initial release, as someone who held out migrating production apps to Swift until v3 I think we all know early adoption is going to be bumpy.

But as of iOS 15+ SwiftUI is very production ready. I’ve migrated two production applications from UIKit to SwiftUI. These have active users and are available on the App Store.

Bloated? The last migration resulted in 79k new lines of code written and 181k deletions after rewriting 80% of the application.

Photos album works out of the box. If you mean camera then there are some issues depending on your use case. Beauty of SwiftUI is we can wrap UIKit views and interop allowing it to play nicely with other frameworks.

If you’re supporting applications that target the last few iOS versions it’s time to learn the new paradigm. Do yourself a favor but most of all anyone who might inherit your codebase.

Try doing performant infinite scrolling on macOS

I primarily do iOS and iPadOS, but it’s far easier to bridge the gap between all the platforms than the experience I had in the past with UIKit/AppKit. My last MacOS app sadly does not do infinite scrolling.

Off the top of my head, I’d consider the approach. Is it a ScrollView? A LazyVStack? What do your view redraws look like?

Anyone working with Swift Strings back in Swift 1+2 was in for some shockingly bad performance. We adopt, we adapt, and the framework matures.

LazyVStack and ScrollView don't scale (no cell reuse / no unloading). The only option is List which has different behaviors and performance characteristics on macOS including issues with eager rendering

To be fair a LazyVStack handles cell reuse and unloading automatically which is why offscreen content that was previously viewed further back on the list will only maintain the root level state (children in the view hierarchy may and will lose state in order to save memory and energy). How that data is loaded and how you key off Identifiable is also important.

Apple’s own documentation discusses this in detail and for large data sets recommends the Lazy approach. If you’re using List you’re in for some issues.

Where do you see that it does cell reuse? It does not... Their docs only talk about lazy loading, not reuse or unloading, eg: https://developer.apple.com/documentation/swiftui/creating-p...

This is also why LazyVGrid/LazyHGrid are unusable as replacements for UICollectionView

Yes you can replace SwiftUI with UIKit + AppKit - replace the navigation, the text rendering, the text editing, the collection views, etc.

edit: Your link is all about how to use List

I’m on a phone which means digging through Apple docs or WWDC-ascii isn’t fun. But for my recent Insta-like infinite feed on iOS this was very helpful:

https://fatbobman.com/en/posts/tips-and-considerations-for-u...

Your link is all about how to use List

Also... Funny that I'm getting downvoted for correctly pointing out that LazyVStack doesn't reuse or unload views. It's so obvious that they should, that no one can believe they don't.

There are additional links and details about LazyVStack highlighted in the content. I thought the top level article focused on Lists would be more helpful for you.

I followed those links and it agrees with my initial post that LazyVStack does not reuse or unload, and confirms that the only choice for large data sets is List (focused on iOS)

Well the good news is you can keep using UICollectionView or MyFancyReuseView anywhere in the stack or tree of SwiftUI.

People I know who are iOS developers say differently.

The Swift language itself is bloated? Compared to what? Golang?

Something like go, yes. Imo there is benefit to only being able to do things one way, and in swift there are a lot of ways to do everything. A trivial example: why can you bind variables in pattern matches with both case let .some(x) and case .some(let x)?

Because the former works with all associated values in a case, whereas the latter does not. `case let .some(x, y, z)` vs `case .some(let x, let y, let z)`. And the latter exists because you may want some to be immutable and others to be mutable: `case .some(let x, var y, _)`.

In other words, the former is syntactic sugar and having just the latter option would suffice

Yes, but I also don't want to have to go around writing Optional<Array<String>> everywhere, so syntactic sugar is fine.

there's a meme that it has too many keywords, but this criticism is shallow. it also grew a lot of features quickly to prioritize SwiftUI support perhaps with unnecessary language complexity as a result.

I'm an iOS dev full-time now (bootstrapped) and SwiftUI is definitely not production ready if it means that it can be used without needing UIKit introspection hacks. I like it and ship all my work with it, but it is painfully broken and will take years more to mature

IMO UIKit is not production ready without Core Animation hacks.

At least you have the option in all cases.

Yeah. You can get far using SwiftUI as your scaffold but you'll need to have introspection and/or UIKit components to do any app of reasonable complexity.

With all of the continued complaints about SwiftUI I almost wonder if, the specter of the Google Graveyard aside, Flutter would be a better bet. Yeah, it might be a second-class non-native citizen on iOS, but if you’re gonna use a half-baked cross-platform solution why not use one that can also target Android?

You can target Android with Swift/Swift UI with SKIP.tools (skip.tools) and SCADE (scade.io), both of which use native controls on Android as well.

I always hear about projects like this or even back before Swift, like Codename One which allows iOS apps to be written with Java and my question is- does anyone actually use these? Why do this rather than use React Native, Flutter, Kotlin Multiplatform, even .NET MAUI or whatever Microsoft is on? One would assume that if these were good solutions more people would be adopting them.

Why is Codename One lesser than Flutter?

Plenty of companies/people use it. It's open source with commercial backing. It's free for commercial use. It existed well before flutter. Uses a language people actually use (Java) as opposed to Dart.

Why would people use flutter which is constantly in danger of being spring cleaned by Google since it makes absolutely no commercial sense. Without Google's support it becomes an unsustainable over engineered brick of code.

Maybe it’s a marketing and perception thing. You’d hear more about PhoneGap or Cordova even than Codename One.

It doesn't have the same level of traction for sure. But it's still popular enough and has support unlike PhoneGap which was discontinued. There are advantages to working with smaller companies where you "know" the individual contributors.

It also came out way after PhoneGap and wasn't backed by a huge company with a huge marketing budget.

Skip is very new. It's interesting because it lets you use SwiftUI and results in human-maintainable Kotlin/Jetpack code, so you can walk away from the tool (although you can also now run Swift on Android too without transpiling)

I have no idea how well it works on iOS, but on Mac it's a sluggish black box api that could otherwise have some potential. There are workarounds, there are some nice components you can put together, but for me it was a little defeating to continue bashing my head against it.

[flagged]