It screws over higher-end devices though. One of the reasons I bought an LG G3 was the "laser auto focus" whatever, which actually did make it insanely fast to take an in-focus photo. It was way slower with Snapchat, and I couldn't focus on anything closer than about 3 feet.

I kind of blame Android too, as a dev I know how crappy the camera APIs can be. But as a user, it stands that only Snapchat takes crappy photos because it doesn't use the standard API, everything else works fine. (Okay actually Facebook Messenger does this too, but oddly the main Facebook app does it right).

Screws over! Oh no!

Good thing it still has the native app

Is Snap obligated to transport your high-res images via the agreement you have when using their software?

Sounds like a market opportunity for software that doesn’t screw you over

I'm not sure how you can think your sarcasm adds anything to the conversation, nor how it could be warranted.

In case you haven't noticed, Snapchat main hurdles these days is that their growth is vastly slowed down by the "stories" timeline on the Facebook app (Instagram, WhatsApp, messenger) that do offer higher quality of pictures.

I don’t really see how histrionics over a tech company in a so-called free market with an obligation to make money, not “not screw over users” adds anything to any conversation

We’ve been here before. Especially on this HN. The whole setup itself is banal

Are we supposed to sit here and fix their problems? What point does that serve

It’s like forcing an author to change their story.

Get over it, America! No one cares about gameifying Silicon Valley

Taking the easy route was OK when they were a scrappy startup, but now that they are a multi-billion public company, I honestly don't see why they can't hire a couple of qualified Android devs to fix this.

It's never really about the devs. It's about creating buy-in from management to support the work that needs to be done. You'll be hard-pressed to find leadership that is generally willing to re-architect/re-engineer apps from scratch without significant pressure from somewhere else in the org other than engineering.

Technical debt is always the last concern in the product. But for once, it's manifesting itself as a real user-facing problem which was acknowledged in the last SNAP earnings call for the Android app.

Ugh and I thought that "The Camera App Company" that only hires rockstar engineers would be different...

Doesn't Instagram use the same approach on their Stories Camera on Android? Seems more of an issue with Android Camera performance/APIs than an engineering critique.

So you prefer gimping your photo quality because you're too lazy to learn how the API works, and assume that your users are OK with this as well?

Aren't the photos on Snapchat intended to be ephemeral? I'd be totally okay with potato quality if I was sharing something quickly because Snapchat isn't a photography app.

It's not as if Snapchat are a tiny company with nobody smart enough to notice there's a camera API, this is intentional.

If you want to send a quality photo to a friend, there are apps for that.

"snapchat isn't a photography app"

you literally take photos and send it to people

Snapchat is to photography as passing notes in class is to literature

Sure, but it's a sticky note, not a novel.

> Aren't the photos on Snapchat intended to be ephemeral? I'd be totally okay with potato quality if I was sharing something quickly because Snapchat isn't a photography app.

This hasn't been the primary focus for years. You can now send Snaps that don't expire after a time limit, and can save your snaps to your storage or Snap's cloud storage (called "memories").

The non-expiring snaps still disappear when you close them; they just don’t auto-close. I guess there’s memories, but I doubt most people take photos just to put in memories.

We ban accounts that show up just to violate the guidelines. If you'd like the account to be unbanned, you can email us at [email protected].

https://news.ycombinator.com/newsguidelines.html

Please follow the HN comment guidelines: https://news.ycombinator.com/newsguidelines.html .

Snapchat (the company) defines itself as a camera company. This can be seen in their IPO and SEC filing documents. And I bet it has a lot to do with their snapchat spectacles.

I've used some pretty recent Android devices which take 1-2 seconds to focus and capture using the actual camera, so I see where he's coming from. Done > perfect when you're trying to capture something happening RIGHT now.

Hate to break it to you, but Snapchat still struggles to focus quickly. Probably because they're using the viewfinder's built-in lower resolution to perform the focus action, which further hampers its ability to focus on an object accurately

We we're doing video, so we are using Camera1 (and Camera2) where its available, but its a bad situation. Lots of obscure devices we don't have access to test on fail regularly and users blame us not Android. The API is clumsy and broken, not just difficult to use.

If I was making an app with photo taking capabilities, I would explore the Snapchat route. Obviously Snapchats users are ok with this for the most part.

This^

I have made countless cross-platform AR apps for mobile and desktop. Never an issue with WebRTC/getUserMedia, iOS, windows, etc. However Android is always a nasty problem. From incorrect aspect resolutions, image stretching, silent fails. Each device needs a custom fix which is time consuming and costly. No wonder why Snapchat went an alternative route.

Are time-consuming custom fixes still commonly required in other (not camera reliant) Android apps too? I haven't really done any Android development since I had a Galaxy phone four years ago because this problem really turned me off to making hobby apps for Android.

The camera & low-level video encoding / decoding are the most device-specific quirky in my experience. If you're making something that is just "software" it's all pretty standardized, but when you start accessing the "hardware" (video codec, camera, possibly low-level audio) is where the device specific differences catch you.

It sounds like he does understand how the API works, doesn't like the way it works, and has decided that for the scope and goals of his project, doing things the fast and low quality way meets the needs of his users.

How often is the Venn overlap of "High Quality Photo" and "OMG Selfie!" exceedingly relevant?

What kind of photo quality do you need to take a selfie to send to your BFF with cat ears drawn on?

Why not implement both and have the screencap method for devices with device specific issues or at leat have an option to use both.