spenvo

I submitted with a hesitant title because I'd genuinely love to know, and I'm surprised there isn't more concrete info on this that's readily available. My strong suspicion is that they don't, and 9to5mac editor has chimed in on twitter saying: "Definitely feels muddy, but think Apple is probably considering FB ads as part of the 'outside goods and services' category. Guideline 3.1.5a makes apps use direct payment for those".

If that explanation is true ^, then it's pretty rich, because Apple recently aimed to get 30% of virtual experiences offered through Airbnb. How would those not be considered "outside goods and services" when they involve people outside the app providing goods and services? [0] Others are saying Apple doesn't see it as an "in app purchase"; however, I can click "Place Order" for an ad in the iOS app... I'd call that an in-app purchase! Can all companies let you buy digital stuff within the app with non-Apple payments or in a bill-you-later manner? Just ads?

Almost certainly there have been behind-closed-doors discussions on this, as the line has been arbitrarily drawn (either way) to include/exclude this massive company from the 30% tax. Indies don't have the same clarity on the rules; for example, Marco Arment's app Overcast sells ads, but doesn't complete transactions in the app because he was worried he'd need to give up 30%. Like with Apple's quiet program that let Amazon and a couple other token companies get a separate deal on content-app rules [1]: how can small companies on the store know when to press Apple on some rules and not on others (without retaining lawyers)?

It's just baffling because Facebook has recently whipped up quite a stir [2] around Apple requiring 30% of creator revenue, yet none of the articles mention this point about Facebook ads getting/not-getting a 30% tax for (probably the better part of) the past decade ... their bread and butter!

Furthermore, Facebook is whining about Apple making IDFA tracking opt-in on iOS, yet this company has benefited HUGELY from the fact Apple didn't do that from the start AND somehow decided not to charge 30% on its ad buys on mobile.

[0] - https://www.nytimes.com/2020/07/28/technology/apple-app-stor...

[1] - https://stratechery.com/2020/apple-amazon-and-common-enemies...

[2]- https://www.google.com/search?biw=1440&bih=798&tbm=nws&ei=RR...

Thanks for saying hi, and done!

Yup. That was of course a big reason I incorporated, but Apple's EULA on its own (and probably the play store's too) is likely sufficient protection for many indie devs. (Many thousands of indie devs launch profitable apps without incorporating.) Anyway, I'm not blaming anyone, I just think that step of mine may have been premature.

Oh getting paired with locals is very cool! I did it a couple years ago, and it was worth it -- but I wish some in my group had been from around my city, Austin. My project ended up shipping (https://www.currentkey.com), and it was nice to be accountable to a few other people through an important stretch and have regular reality checks. I'd strongly consider doing this again for my next project (a mobile game), especially if I could be paired with locals.

If I had one regret, looking back on the experience, it would be a mistake I made: forming an LLC far before I needed to, largely to be seen as a 'company' by YC. You can (and I'd say in some cases should) validate your project, esp. if you're a solo founder - by launching an app as an individual developer vs a company account. I know YC itself is only interested in companies, but they should appreciate that if this school is open to all -- all people don't need a company to have a profitable project.

Report from Republican US Senator Burr "The latest installment examines the sources, tradecraft, and analytic work behind the 2017 Intelligence Community Assessment (ICA) that determined Russia conducted an unprecedented, multi-faceted campaign to interfere with the 2016 U.S. presidential election. The installment builds upon the Committee’s unclassified summary findings on the ICA issued in July 2018." https://www.burr.senate.gov/press/releases/senate-intel-rele...

Enjoy! And thanks for the kind words

Native apps can take advantage of OS APIs that are much richer than those via the browser (or Electron) pass-through APIs.

For example, I've made a Mac app that lets you customize your Spaces (virtual desktops), assign names to them, jump to specific ones, track your time spent across them, and trigger custom events when you move to specific ones. None of this would be possible via a web app or electron app. Project homepage https://www.currentkey.com, app link: https://apps.apple.com/app/apple-store/id1456226992?pt=11998...

And as long as there is differentiated hardware between platforms, there will be opportunities for innovative native apps. For example, though I personally don't love the Touch Bar, there are interesting native app projects around that like Pock: https://github.com/pigigaldi/Pock

If you're having trouble clicking the links above, these should work:

Blog with demo video: https://spencerdailey.com/2020/05/07/how-to-give-each-of-you...

CurrentKey free on the Mac App Store: https://apps.apple.com/app/apple-store/id1456226992?pt=11998...

Featured app, Broadcasts: https://apps.apple.com/us/app/broadcasts/id1469995354

Sorry about that, thanks!

Context: https://www.reddit.com/r/nyc/comments/fayko1/my_covid19_stor...

What are the top reasons an PWA wouldn't cut it?

If I understand this, this model (dkm, "dynamic kernel matching") is to sequences as convolutional networks are to images?

As someone who has built a stats app for macOS, I wish you the best! Cross platform is a big deal and something I never got around to. I had trouble finding a business model that worked - have my upvote!

how is this "top of HN" worthy? bot campaign?

Looks like it, thanks I'll update the top of the article. The basic and disruptive full-screen UI is still the only option for receiving calls

I decided to expand on this comment. https://news.ycombinator.com/item?id=21590920

Its responses:

> I use Slack very often, and I also get annoyed that Drafts features often tugs a frequently-used channel to a different spot in sidebar. "Where did that channel go?" -/jmccaf

> First time that happened I had no idea where it went. Still don't and it's happened a few times. They killed my flow. I hate this "feature". - /markdog12

> I am so glad you said this! It drives me mad. I think of the lists of users/channels in slack alphabetically so even now that I'm aware of the "drafts" change I still go through this shock every.damn.time. - /libraryatnight

Another thing in Slack that has annoyingly changed (without an option to toggle off) is: its "Drafts" feature - where leaving a channel with an unfinished message means that the channel itself gets moved to the top of the left sidebar. This completely breaks my flow, because 1.) you can no longer use up/down hotkeys to reliably go between specific channels, and 2.) I frequently have to do a double take and ask, "where did that channel go?" - especially if you Star specific DM channels, because those go under the drafts section but above the rest of the channels, meaning the Drafts section is out of view most of the time.

Long ago I created a Chrome extension that reordered things nicely, but their CSS changes frequently which made it a maintenance hassle, and I read on HN another dev saying doing so is against their terms of service anyway. Not a fan of that anti-tinkering attitude.

SLACK: don't make dramatic changes to a user's workflow without giving a simple toggle to preserve old behavior.

I get it, most users probably love this feature. My wife does, for example, and she works at a big organization, which has different needs from my workplace. But even if dramatic changes to product are approved of by 75% of users, every time you do so, you create whiplash for the other 25%, and prevent many from ever loving your product. Rinse and repeat that whiplash too many times and product design rants on HN with 600+ upvotes will be a regular occurrence...

Hi there HN - developer here! A bit of context: Five months ago I launched this app, and so far I've had 850 installs and 55 in-app purchases.

The daily install rate bottomed out a few months ago at an average of ~2 installs per day, currently I'm around ~5 installs per day. I get a bunch of emails from users (I include a Feedback button in the app, and probably the most successful feedback forum was posting in r/Apple on their "Self-Promotion Saturdays" deal. ( https://old.reddit.com/r/apple/comments/by86cy/theres_an_app... )

I've pushed out over a dozen updates so far, but am transitioning into a slower release cadence, I wrote about that here ( https://spencerdailey.com/2019/10/18/about-currentkey-2-0-an... ) If anyone has any questions, shoot away! :D

They don't buy them, I believe they lease them

I think this breaks YouTube's timestamped ("share at") links. So, if a user shares a timestamp link (?t=55), and then the creator cuts X seconds from the beginning of the video, the timestamp link will start X seconds after the user intended it to.

A product change that's this ill-considered, half-baked, consequential, and poorly communicated makes me wonder what the UX design process looks like at YouTube.

Fair, my reasoning for saying "now": the ability to alter videos is a relatively new feature (last few months) that YouTube did not make a clear announcement about on launch day.

It is a major departure from immutable videos, and deserved more of a company PR effort to inform users of the change.

Snapshots of video are extremely expensive compared to snapshots of plain text.

Removing words or content changes the meaning of the video, and it does not take a great imagination to see how this would be abused by some.

In any case, adding an asterisk next to the timestamp (as YouTube on its own comments, is a trivial task that shows Google cares one iota about authenticity on its platforms

Thank you!

I'll take your question in two parts:

Fortunately this app uses public APIs only, none of which are marked as deprecated (yay!). Because it's delivered via the store it's fully sandboxed and only needs a couple of (pretty pedestrian) entitlements

You never know until you submit to the store for review what will happen, and they ended up being completely cool and helpful. I did have a backup plan in place (i had round-tripped all that was needed for out-of-store distribution), but I'm really glad it didn't come to that.

This is my first Swift app, so maybe that has a lot to do with it, but I found macOS development requires "scavenger-hunt driven development", where you're literally using Xcode autocomplete to discover attributes and methods on system-provided objects. It's doable, but there's a lot of sleuthing involved and docs and tutorials can be a bit sparse.

Finally, the app did have to go through a couple rejections, but those were for missing some aspects of the Human Interface Guidelines, not the app's core functionality. All-in-all, by the time I launched, I think four versions of the app had been accepted (but not released to the public). (The first one was before I added in-app purchases, to test the waters)

Sure. Each of these false starts were implemented before being abandoned. D'oh.

First: I planned on delivering outside the Mac App Store. This involved updating via the Sparkle cocoapod framework and fulfillment through Stripe. What I found was that the whole process, from downloading and getting going to paying, was very high friction. Every middleman was scaring the potential user: Chrome would warn about the .zip file. MacOS would warn with a scary dialog (even if the app had been notarized). As someone who is wary of downloading apps off the internet, it crossed the line from what I would have done.

I'm also a one-man shop, so I was spending an inordinate amount of time working on fulfillment infrastructure, not improving the app itself. Enumerating other considerations: outside the store I'd have to know more about my user (a bad thing for me since I'm privacy-first), the long-term drain on resources (time and server costs) is higher, system complexity is way higher than through store.

You can always decide to launch outside the store at a later point in time if it's justified, and i've already round tripped the fulfillment process, so that wouldn't be too hard to roll out. All that said, I decided to target an App Store launch in early February.

Next up: I implemented Free Trial. Users would have 14 days to try the entire app for free, then have to make a decision. Ultimately, this also proved high-friction because Apple requires users to "Buy" (not "Get") the free trial as an in-app purchase before they could start using the app, which meant another ~90 seconds and potential confusion on the user's part before getting to try the app.

I landed on freemium for a few reasons: 1.) I know the basic free app can stand on its own as something users would enjoy, 2.) it was frictionless for users to get started, 3.) the install base would be higher because there's no "buying cliff", 4.) it allows me to package two completely different power user sets into distinct upgrades-and therefore, hopefully, capture more total value.

Hi! Dev/maker here,

This app helps you track time spent across apps and virtual desktops on your Mac and is free in the store today. [0]

I'd be happy to answer any questions about the making of the app or macOS/AppKit development in general. This took about 12 months to complete, was my first Swift app (been programming other stuff, mostly web, for like 8 years) and originally started as a project focused solely on adding a unique icon for each virtual desktop (those things that Macs let you create in Mission Control, they call them Spaces). The project veered toward stats (which have way more mainstream appeal) about half way in -- so the end result is app stats which have rich context (which virtual desktop you were in you used them).

The business model has changed multiple times and landed on freemium via the App Store. Originally it was to be delivered outside the store, then it was going to have free trial, then, finally, freemium.

[0] - https://itunes.apple.com/us/app/currentkey-stats/id145622699...

Excellent, I'll add this to the article. No idea why my post went from #1 on HN to the third page in under 30 minutes, I thought we were having a fruitful discussion here

I agree there’s a lot the carriers could be accomplishing in flagging “inauthentic” behavior of network participants, the root cause of SS7’s lack of authentication and encryption will remain and the problem will fester. Yes, carriers are definitely on the hook for making things better too.

That said, the decisions in Apple's client side software are atrocious for the considerations of 2019.

Aside: No idea why my post went from #1 on HN to the third page in under 30 minutes, I thought we were having a fruitful discussion here

Could that product be Android or does Huawei use a non-Play store version that is exempted?

I'm sorry, but I don't buy the need to be sensitive toward optics of evicting defaulting homeowners when the government rounds up and exports populations en masse. See internment camps, dam clearing, etc.

Furthermore, you're completely sidestepping the most dystopian aspects of the social credit system, which takes peoples' personal views into account and is as much a vehicle for thought policing as anything else

Tl;dr: Apparently Apple Geniuses ask customers who are dropping off their Mac for an off-site repair to turn off their admin password.

Despite the fact that: access is not needed for some repairs where they ask that Question and there's a more secure option available: transferring the device password to Apple's CRM, where its use is auditable.