Electron apps cannot be submitted to the Apple store - <AUTHOR> https://david.dev/you-cannot-submit-an-electron-6-or-7-app-to-the-apple-store <comment><USER2> The basic concept isn't too disturbing; Apple packages private APIs that have no guaranteed behavior or expectation of support. If you depend on those APIs, it's very possible that your app will break in a future OS update.

This is conceptually no different than calling something in the sun.* packages in Java. For years it was ok, and then ... it wasn't.

This, however, is draconian:

> Continuing to use or conceal non-public APIs in future submissions of this > app may result in the termination of your Apple Developer account, as well > as removal of all associated apps from the App Store.

"Keep trying to submit, and we might just ban you forever" is insane. Every program of any complexity depends on third party libraries, and many people wouldn't be able to tell what arcane APIs their dependencies (or their dependencies' dependencies) call. "If you continue to have an upstream dependency that violates our terms, we might permaban you" is bullshit.

It's also completely unsurprising. Apple has no love nor concern for their developers anymore. It used to be the premier development platform in the world. Now it's ... I don't even know anymore.

<comment><USER3> What's bullshit about banning someone who has been notified that they are in violation of the rules and then tries to hide their use of private APIs rather than stop using them? That's exactly what I would do in Apple's position. Resubmitting the same thing and hoping that it doesn't get caught the next time isn't an honest mistake.

<comment><USER4> > then tries to hide their use of private APIs rather than stop using them > [...] Resubmitting the same thing and hoping that it doesn't get caught the > next time isn't an honest mistake.

This is missing the point of the post you are replying to. Say you identify five closed API dependencies and remove them. Do you resubmit? If you missed any others, you and all your apps might be banned.

<comment><USER5> How exactly do you miss a dependency?! If it's not your code, then it's a dependency that you need to look at.

<comment><USER6> Dependencies of your dependencies! Imagine installing a library that depends on a couple dozen libraries in its own right. You may not have time to inspect every single node in the dependency graph.

<comment><USER7> > Dependencies of your dependencies! Imagine installing a library that depends > on a couple dozen libraries in its own right. You may not have time to > inspect every single node in the dependency graph.

Excuse me, are you, the developer, telling me, a user, that you don't know what you're giving me to run on my computer?

<comment><USER8> Is that a joke? Surely you aren't suggesting that developers should have full knowledge of all transitive dependencies that compose their application stack.

<comment><USER9> as CTO I know all the dependencies in the application stack of our company and I require developers to have sufficient understanding of their purpose, licensing model etc. There are tools to simplify this task. It's much harder to do for TypeScript than for Java, mostly because NPM ecosystem is a huge pile of junk, but it's still important part of developer's job.

<comment><USER8> > _as CTO I know all the dependencies in the application stack of our company_

You know all of the _transitive_ dependencies in the application stack of your company? Out of curiosity, what is the ballpark figure on the total number of transitive dependencies in your application?

<comment><USER9> Hundreds, mostly because of the JS nonsense. Our Java microservices are lean and strictly controlled.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> > I did write back to Apple trying to explain that I am using Electron and I > can't really change any of these public-framework usage

Yeah. So? By linking a framework that's using private APIs, this becomes your problem now. And Electron's problem, by extension. Go bug them, not Apple.

<comment><USER11> How short are memories.

I remember how Microsoft was vilified for supposedly having secret Windows APIs that allowed Microsoft apps to get better performance.

That was mostly made up and even if such APIs existed, any program could have used it.

Even at the height of corporate arrogance Microsoft didn't dream of banning developers for using undocumented APIs.

Apple seems intent on becoming more evil than Microsoft ever was.

At some point the goodwill they built as underdog making great products will run out and some government somewhere will take an anti-trust action.

I'm just hoping it'll happen sooner rather than later.

<comment><USER12> Apple wants to own the user's machine. They want to make it so their computers run only the software they approve. This is already true for iOS and it's only a matter of time before it also becomes true for macOS. It's the opposite of a free system.

Giving up software freedom for "ease of use" seemed like a fine deal at first but then Apple started making decisions that don't quite align with what neither users not developers want. Apple has already started taking advantage of their position as the gatekeeper of the platform.

<comment><USER13> As a user of macOS, I want developers who makes apps to use public APIs that will be supported so I don't get breakages on system upgrades or migrations.

<comment><USER14> As a user of macOS, why don't you put the onus on Apple to not artificially limit what developers can offer you without it breaking on upgrades and migrations?

Some of the private APIs being used have been stable for generations and are clear improvements in one way or another over the publicly available APIs (like CAContext stuff). I mean a modern OS is not like a library you stick up on NPM and hope no one tries to use internal methods that you'll end up having to support. There are so many desperate teams working on OSX and the applications from Apple that use these APIs, it's not like backwards compatibility, documentation, and most of the issues public APIs face aren't _already_ an issue that has to be tackled.

Apple uses these APIs to make features no one can fairly compete with, which is detrimental to you, as a user, and to external developers. Imagine if any app could use APIs like the ones that Apple Music uses to have tight integration with Siri, or that Apple Maps uses to show on your lockscreen.

<comment><USER5> > There are so many desperate teams working on OSX and the applications from > Apple that use these APIs, it's not like backwards compatibility, > documentation, and most of the issues public APIs face aren't already an > issue that has to be tackled.

When push comes to shove, Apple can tell those teams to rewrite their code. It can't do that to the authors of, say, Firefox.

<comment><USER14> What are you talking about?

They literally do it regularly, public APIs get deprecated then removed and consumers have to rewrite their code.

This article is literally about Apple making 3rd parties rewrite their code just to access the app store.

And before you or someone else points out "Firefox is directly distributed", I say: Exactly. So they can use the internal APIs as they please, then Apple can remove then as they please and break Firrfox and... make Firefox rewrite their code.

Apple is not Microsoft. Apple does not work towards not breaking existing software, they actively break it with each macOS and iOS release, sometimes not even releasing the tools needed to fix them before general releases

Making an internal API people are already using public literally does nothing but _optionally_ allow Apple to give a heads up about deprecation. Apple could literally slap "public" on every internal API, break them every release, and the result would be no different than the current status quo because of the overarching rule of App Store admissions... your app has to work, regardless of if an "internal" or "public" API is changed.

Honestly for most developers that wouldn't seem to different from the current situation: see iOS 13 where basic UILabel stuff was breaking.

And again, apps that don't use the App Store already use internal APIs and can already break all the time.

<comment><USER15> Apple rarely removes public APIs without any deprecation warning that appears when you compile your app at least one version ahead of time.

<comment><USER14> Apple often straight up breaks the implementations of public APIs leaving developers scrambling to fix them. See modals in iOS 13, or title bar styling.

I work at a development agency and on both macOS and iOS every release is a race to figure out which breaking changes have been sprung by Apple (including crashes caused by silent changes in behavior of existing APIs, people have had apps rejected for breaking on pre-general release OS versions when we didn't even have the tools to test them yet)

<comment><USER15> There is a difference between breaking a public API which is a defect and that's done unintentionally - that happens with every operating system and framework - and depending on private methods to behave appropriately.

Decades ago, when Apple introduced 68040 Macs, a lot of programs broke because they were writing self modifying code and that didn't work with the 68040 cache. Whose fault was that Apple's or the developers?

<comment><USER14> It is not a defect. It is literally intentionally broken! Do you actually know this space?

The modal example, it's to support new design language Apple is pushing, straight up breaks modals designed a certain (valid) way.

Catalina removed XML exports used by music apps. There was no deprecation warning.

Apple's recommended fix? Don't update if you need one of those apps.

These are not defects, they are literally breaking changes intentionally made with no warning.

I don't understand why all of you seem to be operating underthe assumption apps using "public APIs" just work with each OS update. It just doesn't work like that. They break and crash not due to defects but due to intentional changes

<comment><USER15> It was part of the _first_ beta release that the new iTunes wouldn't support XML exports. So there was warning that it wouldn't work. Public API's doesn't mean "something will never change". It should mean that API's won't change between minor version numbers. The entire purpose of semantic versioning is that there might be major breaking changing when there is a major release.

Apple did in fact provide a method to share music between apps and some apps do take advantage of it. Do you really think that Apple didn't need to do a major overhaul of iTunes?

Of course it's Apple's advice and common sense not to upgrade your OS until the apps you use are updated to support it.

This is all modern software engineering 101.

As a developer there are a few expectations.

\- depending on private method may break your code with any point release. The vendor has no obligation not to break code if you depended on a private API.

\- If your code breaks calling a _public_ method during a point release, it is a _bug_ and the vendor has an obligation not to break public API's when releasing a point release.

\- If the vendor makes a breaking change during a major release (x.0.0). It's the vendor's responsible to communicate the breaking change and give enough notice to developers/users about breaking changes so that either the developer can fix their code, the user can find a replacement app, and/or the user not upgrade.

<comment><USER14> You spent so many words to latch onto a single part of my entire comment, construct a strawman around it, and burn it down.

But lo and behold something useful did come of it, I finally found the fundamental misunderstanding keeping you from understanding what the crux of the issue is.

> If your code breaks calling a public method during a point release, it is a > bug and the vendor has an obligation not to break public API's when > releasing a point release.

Not when the vendor is Apple.

This whole time you've been operating on the set of rules that apply when your vendor considers you a partner of sorts, maybe in the vaguest sense of the word, but a partner nonetheless.

iOS point releases break things _literally all the time_. Iirc we actually saw _more_ fires on 13.1 than 13.0

This literally has nothing to do with semantic versioning or whatever else you want to confuse it with. It's a blatant disregard for developers that Apple has carried throughout it's operations, from APIs to app store rejections. If anything the only reason they get the slightest pass is they're not Google, who manages to make talking to a human, no matter how hard they stonewall you, a selling point in mobile developer relations now.

<comment><USER15> No one is going to argue that this entire release cycle hasn't been a clusterfuck and the rapid release cycle of iOS/MacOS/watchOS this year is evidence of that.

But your argument has nothing to do with this submission - using _private APIs_.

At least one of your two examples - getting rid of XML exports - wasn't about Apple breaking a public API during a point release. How is it a straw man refuting one of your major points? It was about Apple changing an API during a major release and letting developers know. This is how a vendor should behave.

Now whether they gave developers enough of a warning is a completely separate argument.

BTW: While it is a major change and no longer automatic. There is a manual workaround...

[https://djtechtools.com/2019/10/10/update-to-catalina- heres-...](https://djtechtools.com/2019/10/10/update-to-catalina-heres-how-to- manually-export-your-music-app-as-xml/)

<comment><USER14> My point with that example was about how Apple doesn't treat developers as partners, something I said _multiple times_ in my other comments is the crux of the issue, which this whole internal API in Electron rejection issue is simply a symptom of.

You ignored my perfectly good example of Apple breaking an API because you have nothing to say about it.

You ignored my comment you just replied to pointing out how irrelevant sem-ver is when your "vendor" doesn't care about you.

You are fixated on trying to nitpick the one tiny foothold you've found for your screed, one which only exists because you're ignoring the initial point _I, not the article_ brought up, that this is an issue with Apple not caring about developers _literally in the first comment you replied to_.

Maybe spend more time reading and less time replying.

<comment><USER15> You gave two examples - the one I know about "broke" with a major version release, was known during the beta period and is exactly how a platform vendor should behave. The only thing in question was the beta period long enough. The other you didn't say whether it was a point release or an iOS 13 change.

The electron rejection is not a symptom of Apple breaking a _public API_. It's just the opposite. An API change didn't break Electron apps - it was rejected for using a private API.

It's not "nitpicking" to point out that your examples are completely irrelevant to the submitted article - Apple rejected an app that used private APIs. None of your examples have anything to do with the submitted post.

Would you also complain if you wrote a C program that depended on documented "undefined behavior"...

      int b= a++ + ++a;

and it broke with the next version of the compiler or broke based on which optimizations were turned on? Yes I am sticking with examples of how irresponsible it is to depend on private APIs and undocumented behavior - something you advocated in other comments because that's the _entire_ point of the submitted article.

<comment><USER14> Again you spend more time replying than reading.

I said this internal API rejection situation of _Apple not treating developers like partners_

Like it's literally right there in the comment you replied to clear as day and yet you manage to muck it up then spend several more paragraphs on a new screed nitpicking your wrongly quoted text.

I'm done replying to this.

<comment><USER15> The internal API rejection _is_ about not treating developers like "partners". You aren't their partner. Internal APIs are just that - for internal employees.

It's dumb to use "internal", private APIs. It always has been. It hurts your products stability, it hurts your customers, and it keeps the platform vendor from making rapid changes.

Microsoft never cared about you as a developer - they would just as easily run over you if it met their business objectives.

<comment><USER14> Ugh, I promised myself I'd stop replying, but I'll ignore most of this comment and correct some obvious misinformation for the benefit of other people who actually read comments.

Microsoft has a history from the earliest days of existence of bending over for developers.

Going as far as to literally to add a special case to their memory allocator to support explicit undefined behavior (reading memory after free) for when a specific game, Sim City.

They avoided writing more than 80 characters on any given line in system.ini, because one specific program would fail to read those lines correctly, then delete the system.ini when attempting to write it back

Microsoft is literally still packaging 16-bit subsystems with Windows 10

Anyone _actually_ interested in learning more about it should read Raymond Chen's blog and learn about the truly insane lengths Microsoft goes to make sure they don't break what developers have done, no matter how wrong it is:

[https://devblogs.microsoft.com/oldnewthing/author/oldnewthin...](https://devblogs.microsoft.com/oldnewthing/author/oldnewthing)

Honestly anyone who doesn't know the lengths Microsoft goes to treat developers as partners doesn't have the base knowledge for the conversation this thread has been about, but I digress.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Putting it together:

This is about submitting an app to the Mac App Store. Apple has had a requirement that apps not use private APIs for a while.

It sounds like Chromium, and hence Electron have had references to some private APIs for a while, but Apple has only recently started enforcing their requirement. (Or perhaps only recently started scanning for these particular APIs.)

It's a little painful for the developers for this to suddenly pop up like this, but it's better than all Electron apps suddenly crashing one day, which would have happened sooner or later when one of these APIs changed or was dropped.

The solution is a Chromium fix to avoid using these APIs, and an associated Electron release to incorporate the new version of Chromium.

<comment><USER17> > It sounds like Chromium, and hence Electron have had references to some > private APIs for a while

I wonder if it has been that way in Chromium since Blink was WebKit and maintained largely by Apple with priority on performance on Apple platforms.

<comment><USER18> Apple's WebKit is safe to compile for their stores. The scripts and macros WebKit has disables use of private API unless you are compiling against Apple's internal SDKs.

Edit: Sorry, no. Only JavaScriptCore is safe for stores, not the entire WebKit project.

</comment></comment></comment><comment><USER19> As a user I am glad. As is custom for all Electron discussions, someone must point out its flaws. Why the dislike, you ask? A picture is worth a thousand 64-bit words:

[https://imgur.com/a/XnCOHUD](https://imgur.com/a/XnCOHUD)

And mind you, GitHub Desktop is taking that much _just for showing a mostly empty window!_ while Fork and Tower are displaying a lot more UI, more controls, trees, custom drawing, more text, and have overall more features (best of all: spell checking for commit messages because all native text fields get it for free.) You can try it on your own machine and compare them.

Now yes Electron has made life very easy for some developers and some apps wouldn't even exist if not for Electron, but why, as a user, should I pick an Electron app over native alternatives?

<comment><USER20> >Why the dislike, you ask?

Nobody is asking that, there's a crowd in here that restates the same three points about memory, performance and native UI about once a week.

I dislike waste, I have written assembly code for tiny processors. And yet, I run several Electron apps on my 8gb 2013 Macbook Air and it runs fine, especially VSCode. I am picking that over my previous choice which was native (vim), because I think it's better.

<comment><USER21> Not every developer runs a Macbook. Like many others for my laptop I use Linux running on a cheap ThinkPad with a quarter of the specs of the one you mentioned. ( I could afford to buy an overpriced Macbook, but I like my rugged $100 ThinkPad. ) As I stated elsewhere in this thread, vscode absolutely chews up my battery power. That's a practical concern. If I run several Electron apps on my laptop I'd be lucky to get an entire commute's worth of battery life out of it.

<comment><USER22> As someone who spent years complaining about the lack of cross-platform apps that I could run on Linux, I'm grateful everyday for Electron and for MS for using it for VS.Code.

The fact that it works the same on OSX and Linux is even better.

<comment><USER23> Linux wasn't exactly lacking in text editors, though.

</comment></comment></comment></comment></comment><comment><USER24> Tracked over at:

[https://github.com/electron/electron/issues/20027](https://github.com/electron/electron/issues/20027)

</comment><comment><USER25> Good. It's time app developers began to treat Electron like the Goliath of a dependency that it is rather than a cost-free shortcut to launching a cross- platform GUI product.

It's no different than any other library or toolkit you would link against normally. You wouldn't be hearing these complaints from a "native" app developer that intentionally picked any other library or runtime that (ab)used private frameworks.

</comment><comment><USER26> Well, why the hell is electron/chromium using private APIs? That seems like the real problem here...

<comment><USER27> Another interesting question is how Chrome itself gets approved for the Apple web store then, right?

[https://apps.apple.com/us/app/google- chrome/id535886823](https://apps.apple.com/us/app/google-chrome/id535886823)

<comment><USER28> That's the mobile version of chrome, which as required of all browsers on iOS, is using the Safari web renderer under the hood.

<comment><USER27> Aha, you're right!

Is the desktop version of chrome not in the app store? Maybe not.

</comment></comment></comment></comment><comment><USER29> There's no drama here.

The oldest copy of the current app store guidelines I could find goes back to 2014:

[http://web.archive.org/web/20140903022336/https://developer....](http://web.archive.org/web/20140903022336/https://developer.apple.com/app- store/review/guidelines/)

"2.5 Apps that use non-public APIs will be rejected"

However this has been known dating back to 2010, so I'm sure someone can dig up an older version of the agreement that says as much.

The fact that Electron is a much easier way to build apps than Swift, Obj-C, etc has nothing to do with the enforcement of these long-standing rules.

<comment><USER30> Why does Electron need to use non-public APIs?

<comment><USER29> My understanding is that it's Chromium that uses these (ostensibly for performance), not Electron, but Chromium is a dependency of Electron.

</comment></comment></comment><comment><USER31> On one hand I am not fond of Apple in general at all. On the other hand when I see developers using Electron as a GUI layer I think it is pure insanity. It is an absolute resource and performance hog that in my opinion has no place outside of browsers context.

<comment><USER32> I'm an old dinosaur who used to do GUI development way back, and while I completely agree that Electron is a beast, I also haven't seen almost reasonably cross platform app toolkit that isn't either ugly, or worse than Electron. So what are the options I am missing?

<comment><USER33> I think that's the sad truth. There are currently no good cross-platform UI Toolkits.

<comment><USER34> wxWidgets. The original toolkit is C++ and rather MFC-like, but there are bindings to other languages that are quite a bit easier to use.

</comment></comment></comment></comment><comment><USER35> It seems mostly reasonable to me for Apple to reject apps that use those features assuming their own apps have to obey the same rules.

Unfortunately if you're popular they seem to let you bend the rules. AFAICT Slack has not been rejected and I believe Slack is electron based.

The issue is in Chromium. I have no idea if removing the API usage will be easy or hard but it's been

[https://github.com/electron/electron/issues/20027](https://github.com/electron/electron/issues/20027)

<comment><USER32> Their own apps certainly isn't following the same rules, newer have, and probably never will unless forced by law. There probably are, and have been quite a feq things on any iPhone/Pad that only Apple apps can do. Although I don't have my ear that close to the ground, they seem to get more and more aggressive about protecting their turf in any way they can.

<comment><USER5> Apple's apps have never claimed to follow the App Store Guidelines. The issue at hand here is when third-party developers are selectively granted exceptions.

</comment></comment></comment><comment><USER36> I'm curious as to how Slack was/is still able to get updates out despite clearly relying on electron. Setting aside whether one agrees with Apple on this move or not, I would be outraged if they are playing favorites with a select few high-impact electron apps that they don't want off their store due to the associated bad press it would garner them.

<comment><AUTHOR> well I guess that when you have the #1 application in the App store (under business) and an 11bn $ market cap you are probably not treated the same way as an unknown developer with a pretty insignificant app ;) OR simply you do have engineers that can patch pretty much anything so run their own version of Electron/Chromium duly compliant with the App Store requirements.

<comment><USER37> This is a problem with licensees like MIT. The essential features will be proprietary.

</comment></comment></comment><comment><USER38> At least Apple in this case actually provided a reason and list of APIs it is unhappy with. Armed with this you could either in theory or actuality chase through the maze of your app's dependencies. If this happened to me I'd then have a fighting chance of moving forward.

On the other hand, plenty of rejections I've anecdotally encountered are far less obvious and boil down to "we say so". Then you get banned while you still wonder. Google have done this a few times to others I know.

Strange times.

</comment><comment><USER39> Off topic: this is the first time I see Latin Modern Roman used on a web page. Doesn't look that great on low-DPI screens (13" at 2560x1440) but looks good on high-DPI (530 DPI Pixel 4 XL).

<comment><AUTHOR> wow glad you noticed :) is latex CSS and I thought it would make the text look different (it looks like everyone is using Open Sans nowadays :) [https://github.com/gurugeek/latexcss/blob/master/latex.css](https://github.com/gurugeek/latexcss/blob/master/latex.css)

</comment></comment><comment><USER40> Is this an attempt by Apple to increase robustness by reducing dependencies on unsigned binaries?

<comment><USER41> I feel Apple is moving into somewhat dangerous territory. If the intent, as documented by internal messages and emails, is purely to protect the consumer by forcing people to use only public APIs, that's one thing.

But, if Apple is trying to apply anticompetitive behavior against certain technologies, if this rule is selectively enforced, if there is any bad smell or anything dirty about this process, then Apple is inviting antitrust scrutiny or new laws.

Apple had better make sure it is squeaky clean on this.

<comment><USER42> This is nothing new, developing iOS and MacOS apps you use public APIs and never use private ones. I have never had any desire or need to use something not documented/public in anything I have built. You'd have to be pretty dumb to depend on something that Apple can and will change whenever they want. When I worked at Apple 25 years ago I remember the source code to the old MacOS was riddled with "if Word version 4.05 do this, if 4.15 do that" to try and avoid breaking Microsoft's apps". It was a nightmarish attempt to ensure buggy software didn't suddenly stop working. I don't blame Apple for wanting to avoid this kind of pain today.

<comment><USER41> Valid points. My worry is if this is being exercised inconsistently. Is the same rule applied in the same way to everyone? Even Apple granting itself exceptions isn't great -- and I know it does grant this exception to itself -- but if it grants exceptions to some third parties but not others, or does not faithfully and consistently enforce the rule for everyone, that would be extremely troubling.

</comment></comment></comment></comment><comment><USER43> While this decision looks rational and technically solid on the surface, it makes the Mac platform, and in particular the Mac app store, even less appealing to developers.

Here on HN we hear constantly of developers dropping out of the Mac app store. If we cobsider the premium (justified or not) of apple laptops, and thus the relatively limited audience they target, we can easily predict a steeper decline in interest to develop for the Mac platform.

Having said that, we should also consider that Electron is indirectly owned by Microsoft, and is based on tech by Google. So I don't see much incentive on their part to fix this quickly, and one could even argue that they have some interest in not fixing at all this.

</comment><comment><USER44> Wait. Does this mean Slack will be banned soon? Or are they all using Electron 8?

<comment><AUTHOR> I am pretty sure the problem will also be in Electron 8.

</comment></comment><comment><USER45> Electron apps can be submitted to the Apple store... Slack has recently been updated for example. This seems to only affect some developers, especially electron <= 5

<comment><USER46> Does Slack use private APIs?

<comment><USER45> No electron application use private APIs, it's the embedded chromium that do.

</comment></comment></comment><comment><USER47> Why doesn't Apple change their SDK to make their API non linkable?

<comment><USER48> Because of how Obj-C works, it's not really possible to have completely hidden classes or methods. You can instantiate classes by name at runtime, and can similarly create a message (aka call a method) at runtime. This is basically the "concealed" option mentioned elsewhere. Because of this dynamism, it's possible to recreate a header file from the compiled frameworks, and then just compile like normal.

</comment></comment><comment><USER49> Well to be honest and at the risk of getting down voted I think a fair amount of readers will agree that you shouldn't submit Electron apps not only on the Apple store but also elsewhere, it may be a good way to get a prototype out of the office but that's about it

</comment><comment><USER47> Why doesn't Apple change their SDK to make the public APIs non linkable?

<comment><USER5> Because they need to link against these symbols themselves. They have used TAPI in the past to keep these symbols out of the public SDK, but it's quite easy to make your own TBD that lets you link against them anyways. (By the way, you posted your comment twice.)

</comment></comment><comment><USER50> I was able to submit my app after an upgrade to Electron 6 with no issue whatsoever.

Only issue was first with the signature of the app, got fixed with later updates.

My app is up in the AppStore with latest Electron 6.

</comment><comment><USER51> Hopefully this will happen everywhere. Electron apps are shit. If you don't want to write a native app. Don't support that platform.

</comment><comment><USER52> Probably not a big deal for publishers - most (non-tech) people I know download Electron apps via their own website e.g. Slack, Notion, etc.

<comment><USER53> Even if its just 10% of your users that installed your app from MAS, that's still a huge problem. 10% of your users you can't ship an update to and have no easy way of moving to your self-hosted updater, that's a major problem.

I personally prefer using MAS for such apps, since that means updates are installed automatically overnight without having to deal with other people's annoying auto-updating software. Wish Chrome itself was in the MAS, so I didn't have to deal with Google Autoupdater.

</comment></comment><comment><USER54> Does this apply to React Native apps?

<comment><USER13> React Native doesn't use Chromium under the hood, it renders using native iOS/Android components not a web view like Electron.

</comment></comment><comment><USER55> Wonder why they couldn't do the same for the iOS appstore. Like js apps based in phonegap

<comment><USER5> They do, but those apps use WebKit and hence don't rely on private API.

<comment><USER56> And similarly, web tech wrapper apps for macOS that use WebKit instead of Chromium are not facing private API usage rejections.

WebKit on macOS doesn't have the limitations that its iOS cousin does… cutting edge API support is a bit spotty but if one looks at how old the versions of Electron being shipped are, that clearly isn't a problem. More web wrappers should opt for the locally available engine instead of bringing their own.

</comment></comment></comment><comment><USER57> Apple does not like platforms that make it easy to publish lowest common denominator apps for iOS. It makes for garbage apps that look the same on iOS and Android and presents a false equivalency. They know most companies care about iOS customers than Android so this forces companies to spend more making the iOS app better than the Android app.

<comment><USER5> Apple did not ban this app for being "garbage"–it's not even an iOS/Android app.

</comment></comment><comment><USER58> So stop using Electron?

</comment><comment><USER59> Good.

</comment><comment><USER60> If Apple doesn't want third party apps calling private APIs why don't they simply run third party apps in a sandbox that doesn't have them exposed?

<comment><USER5> Because the private APIs are used by frameworks that are loaded into the same process as the application.

<comment><USER60> Sorry, can you explain further? I haven't done any mobile development so if you have some resource I can learn more from I would really appreciate it.

</comment></comment></comment><comment><USER61> why not contact Electron for this problem? There must be thousands of people having this at the moment

<comment><USER5> They did: [https://github.com/electron/electron/issues/20027](https://github.com/electron/electron/issues/20027)

</comment></comment><comment><USER62> This is absolutely insane. Apple could learn a lot from Microsoft of how to treat developers. God i miss Steve Ballmer

<comment><USER15> It's dumb too depend on private APIs and shows a complete lack of understanding how development works. Have you read Raymond Chen's blog about all of the obscure one off hacks Microsoft has had to add to keep misbehaving apps from breaking?

<comment><USER62> > Have you read Raymond Chen's blog about all of the obscure one off hacks > Microsoft has had to add to keep misbehaving apps from breaking?

That is precisely why I mentioned Microsoft. They have historically gone through great lengths to keep devs happy.

<comment><USER15> And where has that gotten them? Slow release cycles, unable to compete in mobile and now Apple alone sells more iOS devices than all Windows manufacturers combined. You create a compelling platform for users and developers will come along.

That's what happens when you focus on developers instead of users. How much smaller would Windows be if they didn't have all of these backwards compstible hacks? Hell, they had a half dozen different ways to define a string that you actively had to convert back and forth between just to call various APIs and that was back in the early 2000s. I'm sure it's gotten worse since then.

You don't have to make developers happy. Developers will go to where the users are. Where is all of the development energy these days? It's definitely not on Windows. What makes developers "happy" are paying customers.

Microsoft has been trying and failing for years to produce a viable ARM laptops. Partially because of an insistence on backwards compatibility and all of the code bloat that entails. Apple transitioned the Mac platform four times since 1984 and created four successful ARM based platforms in the last decade.

<comment><USER62> Microsofts failure in mobile has simply been due to the fact that they weren't able to excite users with hardware. This changed with the Surface line.

<comment><USER15> Microsoft's hardware was often the same hardware that ran Android especially from HTC.

But as far as the Surface. MS only made $1.329 billion on Surface devices. That's less than a third of what Apple makes on Macs. Heck that's less than Apple makes on Watches and AirPods.

[https://sixcolors.com/post/2019/10/apple-results-64b-in- reve...](https://sixcolors.com/post/2019/10/apple-results-64b-in-revenue-on- record-services-income/#more)

[https://www.techradar.com/news/microsofts-surface-sales- keep...](https://www.techradar.com/news/microsofts-surface-sales-keep-getting- stronger-with-a-21-leap)

</comment></comment></comment></comment></comment></comment><comment><USER63> Does anyone use the Mac appstore?

<comment><AUTHOR> I think so :) there are several apps that users prefer to install on the apple store, and even a notarized DMG shows some warnings so..

</comment></comment><comment><USER64> Good.

</comment><comment><USER65> So there goes one of the primary reasons to use Electron...

Cross-platform comparability always promises so much, and falls down in the implementation.

</comment><comment><USER66> That's what you get for supporting the Apple ecosystem. Its a closed system.

</comment><comment><USER67> The lesson here is write native apps using the preferred native tools of the platform, and avoid shortcut solutions.

<comment><USER68> I think this is a really elitist and unsympathetic statement. It completely ignores the fact that there are people out there whose only realistic option if they want to release on multiple platforms is to use something like electron. You can preach native all day long but the reality is that some people simply do not have the time (i.e. money) to learn, build and maintain three completely different systems and architectures and at the same time and also build a product. Are you saying that these people should simply give up because you consider it a "shortcut solution"?

Yes electron comes with some overhead. But what you get from paying that price are products that otherwise likely wouldn't exist. Some of these are bad indeed, but some of them are also really good and provide real value.

<comment><USER69> Thanks for sharing this perspective. Some of us have a core competency in a domain outside of CS and want to build niche tools to serve our industry. Electron helps us reach our userbase without excluding one or more platforms. Bloat is secondary compared to the other heavyweight software I have to use.

</comment></comment></comment><comment><USER70> Apple could just not have private APIs. At the very least, they could be impossible to access. If they have to exist at all, they could be in a separate library with permissions that prevent it from being read or mapped into memory.

If the APIs didn't exist, then there would be no need for Apple to check and there would be no developers tempted to use anything private.

<comment><USER15> Again this shows a complete lack of understanding how software development works.

If you have a public function "A" that is implement using private methods B,C,D. The implementor is free to change B, C, D or completely get rid of them to implement A. This is software engineering 101. Apple was able to make multiple cpu transitions doing this. Back in the PPC days, non native apps could run at near native speeds calling public APIs that were implemented by changing the private interface.

<comment><USER70> Put B,C,D on the other side of a privilege boundary.

Most obviously, they can go in the kernel. They can go in a separate process, using the Mach messaging that Apple so loves. There are other designs, as seen in Multics and VMS, with semi-privileged libraries. One could implement semi- privileged libraries on ARM by switching to a different page table when an attempt is made to run the library code.

For secured forms of code like WebAssembly and the JVM, simply validate at load time that there will not be calls to non-whitelisted library functions.

<comment><USER15> There is always a performance penalty when switching between "rings". Private methods are an "implementation detail" that shouldn't be depended on.

Would you write a C++ program that called private functions using pointers? Would you write a C# program that called a private method using reflection? Should the dependency maintainer have the expectation of people calling private methods and not break your code?

Every suggestion you have leads to performance issues.

</comment></comment></comment></comment><comment><USER71> Banning private APIs is absurd. Permanently banning developers for using private APIs is shear lunacy.

As someone else pointed out, not using private APIs would put some applications at a disadvantage against first party software: [https://news.ycombinator.com/item?id=21437673](https://news.ycombinator.com/item?id=21437673)

Firefox is often criticized for it's power consumption on the mac because it is not on par with safari. Chrome/electron uses private APIs to reduce power consumption to be more competitive with Apples browser. Apple bans the use of private APIs.

Monopoly laws need to be updated.

<comment><USER15> _Banning private APIs is absurd. Permanently banning developers for using private APIs is shear lunacy_

An API by definition is the public interface that a platform promises developers will not change without notice. The vendor has every right to change a private API. Once you start letting third party developers use private APIs either you are stuck with them forever or when you change it, users will blame you not the developer when applications break.

<comment><USER71> What a moronic comment. No ware in my comment have I argued that apple should not change their private APIs. What I'm arguing against is preventing third party developers from accessing them the same way apple does. We all understand that private APIs are subject to change without notice and accept the inherent risks involved.

I suggest working on your comprehension skills.

<comment><USER15> It's moronic to use a private method that may change in a minor update. If anyone is using private APIs - they should work on their development skills.

Of course Apple is going to use private methods to implement public APIs. Would it be more sound architecturally if they made all of their public APIs thousands of lines of code and copy and paste duplicated functionality so they wouldn't use private functions?

The risk isn't just to you. Apple has been able to get customers to upgrade their operating system at a cadence that no other platform vendor has. What happens if every time they release an operating system apps break because they use private APIs? Either they will have to take the Windows strategy of putting individual hacks to keep apps from breaking or they will just have to let them break? Microsoft has historically not been able to ship OS upgrades on time partially because of the backwards compatible bloat of Windows.

Apple has successfully done multiple platform transitions by completely changing the underlying code for public interfaces. They wouldn't have been able to do that if developers were using private methods.

In the grand scheme of things, you as a developer aren't and shouldn't be Apple's focus. The customer is. If Apple is able to keep the customer happy developers will come along.</comment></comment></comment></comment>


It's 2012, and there's still no official SIP to Skype gateway - <AUTHOR>

Any idea why Skype does not provide any official means to call skype accounts from a SIP connection? Even a paid interface is not available. The only thing that is available is a paid service where you can call phone numbers from Skype to your SIP trunk
so, there's a huge world of SIP telephony, and another huge world of Skype users. And they don't talk to each other.
I'm not considering dirty hacks which bind Asterisk or FreeSWITCH with a Skype GUI client installed on the same machine. <comment><USER2> The purpose of Skype is to have a monopoly on the namespace and interop threatens that. Realistically, don't most people use SIP with phones that can only dial numbers?

<comment><AUTHOR> there's plenty of ways to assign a numeric alias to a SIP name. For example, I run a virtual PBX with my internal numbering plan. I could assign internal numbers to skype names, for example.

</comment></comment><comment><USER3> Who would make money if this existed? Who would lose money? I have a hard time articulating a concrete benefit for Microsoft that would result from a gateway.

<comment><AUTHOR> as I mentioned in above comment, I already pay for skype-to-PSTN calls, and I wouldn't mind paying for SIP<=>Skype calls as well

</comment></comment><comment><USER4> >so, there's a huge world of SIP telephony, and another huge world of Skype users. And they don't talk to each other.

They do talk to each other, users pay for the privilege.

Think of it as a win/win for skype/sip providers. Just not a win for the users.

<comment><AUTHOR> see my other comment below. I know about SkypeConnect, and it's only usable for particular types of businesses.

the win/win for sype/sip providers is only when the calls go through PSTN beween them.

<comment><USER4> >I know about SkypeConnect, and it's only usable for particular types of businesses.

I didn't mention skype connect.

>the win/win for sype/sip providers is only when the calls go through PSTN beween them.

Do you really think the operators of skype or the sip providers cut the PSTN people in for anything when they don't have to? The only direct through pstn as a last resort.

I have called peoples skype-in numbers from my skype account. I do get charged for this. I am certain it goes through no pstn network.

<comment><AUTHOR> could you be more specific? what exactly service did you talk about in the top comment?

<comment><USER4> >what exactly service did you talk about in the top comment?

Skype.

<comment><AUTHOR> >They do talk to each other, users pay for the privilege.

what exactly service are you talking about? what kind of communication, between which parties?

</comment></comment></comment></comment></comment></comment><comment><USER5> There's an online service called Blue Jeans Network that lets you have a conference call with Skype, H.323, Google Talk, and Microsoft Lync participants.

<http://bluejeans.com/>

<comment><AUTHOR> yes there are some services like this. I tried Comfytel about a month ago: [http://txlab.wordpress.com/2012/01/30/comfytel-com-one- more-...](http://txlab.wordpress.com/2012/01/30/comfytel-com-one-more-free- pstn-to-sip-gateway-provider/)

the problem was, about 30% of calls didn't reach my skype client. I guess Comfytel uses one of those dirty hacks. Probably bluejeans too.

<comment><USER5> I used to work there, and they have a skypekit license. It doesn't use the "spawn a skype linux client and use the plugin interface" method, it's a direct integration.

<comment><AUTHOR> hmm, thanks. It's probably a quite expensive license, as the default developer agreement is quite restrictive: [http://www.mail-archive.com/asterisk- firstname.lastname@example.com/ms...](http://www.mail-archive.com/asterisk- firstname.lastname@example.com/msg48959.html)

any explanation why 30% of calls were dropped?

</comment></comment></comment></comment><comment> iso8859-1 Here's a link for the hack you mentioned: [http://www.personal.psu.edu/wcs131/blogs/psuvoip/2011/12/sky...](http://www.personal.psu.edu/wcs131/blogs/psuvoip/2011/12/skype_for_asterisk_the_hard_way.html)

<comment><AUTHOR> yes, and I'll never run it on my voip server :)

</comment></comment><comment><USER6> "Still no"?

There was "Skype for Asterisk" for a long time, and unsurprisingly it's the first hit on Google. It was killed shortly after MS bought Skype. Life is hard when you buy into proprietary protocols.

<comment><USER7> It was killed shortly after MS bought Skype, but it wasn't MS that killed it.

A year+ before, Asterisk users received an email saying that the contract would not be renewed.

</comment></comment><comment><USER8> So... Skype launched their official SIP service years ago. It is called Skype Connect. They wouldn't provide a gateway because that would cannibalize their low cost SIP trunking service. See <http://www.skype.com/intl/en- us/business/skype-connect/>

<comment><AUTHOR> this service does not allow to call a skype user from a SIP trunk. What they offer is just a regular SIP-to-PSTN service, plus a way for skype users to call into your SIP trunk.

I am paying Skype for PSTN calls already. I wouldn't also mind paying them for SIP-to-Skype and Skype-to-SIP (with any public SIP destination) calls if there were such service.

</comment></comment><comment><USER9> It is complex to fully reverse engineer Skype: <http://en.wikipedia.org/wiki/Skype_protocol>

<comment><AUTHOR> I'm actually talking about officially supported ways of communicating, not hacking

</comment></comment><comment><USER10> and no IPv6.

granted, getting rid of NAT probably means Skype dies

<comment><AUTHOR> I don't think so. They have an easy to use client, and a huge user base. I guess they will also add ipv6 support as soon there's enough ipv6 adoption on the residential market.

I also don't have ipv6 at home from my cable provider, and they don't even tell when I can expect it.</comment></comment>


Introduction to Machine Learning for Developers - <AUTHOR> http://blog.algorithmia.com/introduction-machine-learning-developers/ <comment><USER2> The description of Naive Bayes is misleading. Almost all supervised learning problems assume that "Inputs are classified in isolation where no input has an effect on any other inputs" (quote from the article), but that's not why Naive Bayes is called naive.

The naive assumption made by Naive Bayes is that the _features_ (or attributes) of each input point are independent. Let me explain from a simple example:

Suppose you want to find people who receive benefits they are not entitled to. The input data might have two attributes: cash on bank account, and amount received in benefits. Although you could look for data that have a high value in both attributes, the naive assumption made in Naive Bayes says that you can in fact make your classification without correlating multiple attributes; Naive Bayes assumes you can explain the labeling of data just by looking at attributes in isolation. In this example, this assumption is clearly unfounded, since if you only look at benefits or only at cash balance, you won't be able to tell how a person should be classified.

The data independence assumption made by almost all ML algorithms is that different data points are not correlated: the label of a single data point (person in the above problem) does not depend on the attributes of other data points.

<comment><USER3> I agree. Most supervised learning classifiers are derived based on the independent and identically distributed assumption for each (x,y) pair.

To be more specific about the Naive Bayes assumption, the features of a data point are conditionally independent instead of simply independent. This means that given a certain label, these set of features are independent.

</comment></comment><comment><USER4> I cannot recommend scikit-learn enough to anyone interested in machine learning who likes python. I have been working with it for part of my Thesis, and it can do so much, with so little code. It is amazing.

<comment><USER5> If anyone is interested in learning more about scikit-learn, I'd recommend "Hands-On Machine Learning with Scikit-Learn and Tensorflow" from O'Reilly:

[http://shop.oreilly.com/product/0636920052289.do](http://shop.oreilly.com/product/0636920052289.do)

When I first started using scikit-learn, I was overwhelmed with the number of classes and options available. I just chose some basic classifiers I was familiar with and stuck with most of the default settings. The book explains many of the other models and when they would be useful, but also spends a lot of time exploring the datasets (using pandas), preprocessing data and building data pipelines, finding the best hyperparameters, best ways to evaluate a models performance, etc. The library feels less like a big bag of algorithms now and more like a cohesive data pipeline.

<comment><USER6> There's also o'reilly's 'Introduction to Machine Learning with Python', which is very much about scikit-learn

[http://shop.oreilly.com/product/0636920030515.do](http://shop.oreilly.com/product/0636920030515.do)

Just came out a few weeks ago so it's relatively unknown, I've read the first few chapters and so far it's good! The first author Andreas Mueller is one of the scikit core devs.

The Jupyter notebooks including the book's code are on GitHub: [https://github.com/amueller/introduction_to_ml_with_python](https://github.com/amueller/introduction_to_ml_with_python)

</comment></comment></comment><comment><USER7> For anyone trying to get into the field, I put together a list of resources I found useful:

[https://news.ycombinator.com/item?id=12900448](https://news.ycombinator.com/item?id=12900448)

</comment><comment><USER8> Although I did my studies with NLTK, it looks like spaCy has stepped up to the plate, particular with NLP related tasks.

Worth checking out, in parallel to or in place of NLTK: [https://spacy.io](https://spacy.io)

<comment><USER9> Never heard of it. Thanks for the pointer!

</comment></comment><comment><USER10> For Python programmers Harrison's Website is awesome resource

[http://pythonprogramming.net](http://pythonprogramming.net)

</comment><comment><USER11> I've made a similar list for economists. It included a list of practical applications of ML. Developers can get a sense of what the discipline can do before jumping in.

APPLIED MACHINE LEARNING CASES

## Business

1\. Kaggle, Data Science Use cases. An outline of business applications. Few companies have the data to implement these things. [https://www.kaggle.com/wiki/DataScienceUseCases](https://www.kaggle.com/wiki/DataScienceUseCases)

2\. Kaggle, Competitions. (Make sure you chose "All Competitions" and then "Completed".) Each competition has a leaderboard. When users publish their solutions on GitHub, you can find links to these solutions on the leaderboard. [https://www.kaggle.com/competitions](https://www.kaggle.com/competitions)

Industrial solutions are more powerful and complex than these examples, but they are not publicly available. Data-driven companies post some details about this work in their blogs.

## Emerging applications

1\. Stanford's CS229 Course, Student projects. See "Recent years' projects." Hundreds of short papers. [http://cs229.stanford.edu/](http://cs229.stanford.edu/)

2\. CMU ML Department, Student projects. More advanced problems, compared to CS229. [http://www.ml.cmu.edu/research/data-analysis- projects.html](http://www.ml.cmu.edu/research/data-analysis-projects.html)

3\. arXiv, Machine Learning. Drafts of important papers appear here first. Then they got published in journals. [http://arxiv.org/list/stat.ML/recent](http://arxiv.org/list/stat.ML/recent)

4\. CS journals. Applied ML research also appear in engineering journals. [https://scholar.google.com/citations?view_op=top_venues&hl=e...](https://scholar.google.com/citations?view_op=top_venues&hl=en&vq=eng_theoreticalcomputerscience)

5\. CS departments. For example: CMU ML Department, PhD dissertations. [http://www.ml.cmu.edu/research/phd- dissertations.html](http://www.ml.cmu.edu/research/phd-dissertations.html)

## Government

1\. Bloomberg and Flowers, "NYC Analytics." NYC Mayor's Office of Data Analysis describes their data management system and improvements in operations. [http://www.nyc.gov/html/analytics/downloads/pdf/annual_repor...](http://www.nyc.gov/html/analytics/downloads/pdf/annual_report_2013.pdf)

2\. UK Government, Tax Agent Segmentation. [https://www.gov.uk/government/uploads/system/uploads/attachm...](https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/396175/Report348.pdf)

3\. Data.gov, Applications. Some are ML-based. [http://www.data.gov/applications](http://www.data.gov/applications)

4\. StackExchange, Applications. [http://opendata.stackexchange.com/questions/3346/examples- of...](http://opendata.stackexchange.com/questions/3346/examples-of-useful- applications-that-are-being-developed-using-open-data)

## See also

The original article: [https://antontarasenko.com/2015/12/28/machine-learning- for-e...](https://antontarasenko.com/2015/12/28/machine-learning-for- economists-an-introduction/)

A related list of cases: [https://www.quora.com/What-are-some-practical- applications-o...](https://www.quora.com/What-are-some-practical-applications- of-big-data/answer/Anton-Tarasenko-2?srid=i9vl)

<comment><USER12> I recently started playing around with the data sets on past Kaggle competitions and have been learning a lot.

The Data Science use cases there are quite interesting. Are there any publicly available data-sets (other than the ones available in competitions) to work with (especially for the marketing use cases)?

<comment><USER13> I highly recommend subscribing to the "Data is Plural" mailing list. You'll get interesting datasets mailed to you each week! Here's the last one: [http://tinyletter.com/data-is-plural/letters/data-is- plural-...](http://tinyletter.com/data-is-plural/letters/data-is- plural-2016-11-02-edition)

Also checkout "Academic Torrents". Lots of large datasets here, from millions of Tweets, to labeled photos of fish in the wild. [http://academictorrents.com/browse.php?c6=1&sort_field=times...](http://academictorrents.com/browse.php?c6=1&sort_field=times_completed&sort_dir=DESC&page=1)

<comment><USER12> Thanks for that! I looked it up and just subscribed to the mailing list. Looks quite interesting.

</comment></comment></comment></comment><comment><USER14> Cool, this is a helpful intro. Anyone have any recommended reading for ML in a JVM context?

<comment><USER15> Weka is a popular machine learning toolkit in Java: [http://www.cs.waikato.ac.nz/ml/weka/](http://www.cs.waikato.ac.nz/ml/weka/)

and they have a textbook to go with it: [http://www.cs.waikato.ac.nz/ml/weka/book.html](http://www.cs.waikato.ac.nz/ml/weka/book.html)

as well as an online course: [https://weka.waikato.ac.nz/dataminingwithweka/preview](https://weka.waikato.ac.nz/dataminingwithweka/preview)

</comment></comment><comment><USER16> In the slides for unsupervised learning, what is meant by "Maximum Entropy"? Doesn't this just imply that the distribution will be uniform; i.e. it's no better than making a blind guess?

<comment><USER3> I have only seen a maximum entropy model as part of the supervised realm where it is a discriminative model. In other words, given some labeled data, we can draw a decision boundary. Maximum entropy in this context is almost certainly associated with the information theory definition, where the entropy of a collection of data based on the distribution of classes is measured. High entropy if each class is equally probable. Lower Entropy otherwise.

</comment></comment><comment><USER3> Honestly, this is a good run through of resources and examples of different machine learning algorithms/techniques be it supervised, unsupervised, or model validation... however, the wording used and mistakes made when describing supervised learning or Naive Bayes shows that this is an attempt at taking an O'Rielly book and trying to summarize it in a short article... while making errors... How did it get so many points on ycombinator?

<comment><USER17> Hi! I'm Stephanie Kim and wrote the article. This post and slides were from a talk I gave for a basic introduction to machine learning at a woman's programming conference in Seattle. I did update the language which was a mistake rather than a misunderstanding of Naive Bayes. I have professional machine learning experience and while I am definitely not an expert the talk was geared for web developers with no prior experience in machine learning. Thanks for your feedback.

<comment><USER3> Hi Stephanie. Sorry if my comment sounded harsh and nit picky. I actually passed it off to a fellow software engineer at work and he found it really insightful and useful for the work he is doing. Not everybody makes the effort to share their knowledge and I really appreciate you doing so. Have a good day :)

</comment></comment></comment><comment><USER18> If one understand decently all of that, does he get a job?

<comment><USER19> If you will be able to debug all that, you will get a job.

<comment><USER20> Which is way harder than it sounds.

</comment></comment></comment><comment><USER21> Not even a mention of TensorFlow or Torch?</comment>


Full scale, fully operational 3D printed car. - <AUTHOR> http://develop3d.com/profiles/pit-stop

<comment><USER2> The title here is a little misleading. They didn't create the whole car with a 3D printer. They just used a Stratasys FDM machine (the "3d printer") to make the outer body panels... basically just the outer shell of the car that is painted and polished.

Here is a link to the actual website for the vehicle, instead of the terrible blog write-up: <http://www.urbee.net/home/>

<comment><USER3> Is there anyone who actually believes you will be able to print a whole car?

<comment><USER4> Yes, why wouldn't you? It's just a question of scale.

</comment></comment></comment><comment><USER5> Looks like the site is down. Where can I download this car?

<comment><USER2> Here is the link to the real website, instead of the blog: <http://www.urbee.net/home/>

It's not a full car that is downloadable and printable. It's not at all what the misleading title of this post says.

<comment><USER6> From their website: >By reducing the maximum speed and acceleration of Urbee compared to what many other cars are capable of, we can dramatically reduce the maximum horsepower required to power our car. The smaller motor/engine size in turn decreases the weight of the vehicle and increases the range.

I think this is great, cars are grossly overpowered and under-optimized for their most common use. I drive a 4500lb V6 truck with a ScanGauge, and cruising along only takes 50hp. Without any figures to back up their eco- marketing, though, I'm a bit worried. There are some slow accelerating cars on the market already. Making an even slower car gets into the territory of "dangerous".

I know they might not be able to release numbers yet, but "our car is slow and doesn't have a lot of power" isn't going to help their marketing if they don't do some explaining besides "power = energy".

</comment></comment></comment><comment><USER7> Here's a short video of their prototype: <http://www.youtube.com/watch?v=2JpIj9IN924>

Looks like at least the current prototype uses printed panels on top of a steel spaceframe, so probably "3D printed car body" would be a closer title. :) Still damn cool!</comment>


Ask HN: What did you spend your first real job paycheck on? - <AUTHOR> <comment><USER2> I always wanted compilers, but could t afford Borland C++ which meant I was stuck with QBasic and older C/Pascal compilers thag could only make .com files.

So my first purchase was Visual C++ 4. Programmed my ass off for a whole week.

I then discovered cars and started spending all my time and money on that.

<comment><AUTHOR> >> I then discovered cars and started spending all my time and money on that.

Haha, cars seem to be a black hole for all the money people make.

>> I always wanted compilers, but could t afford Borland C++ which meant I was stuck with QBasic and older C/Pascal compilers thag could only make .com files. So my first purchase was Visual C++ 4. Programmed my ass off for a whole week.

Coming from a Java background, I couldn't have imagined people paying for a compiler. Times surely have changed!

</comment></comment><comment><USER3> I treated my parents to dinner.

</comment><comment><USER4> Gasoline.</comment>


Why do Germans shun Twitter? - <AUTHOR> http://www.economist.com/blogs/babbage/2013/12/social-media

<comment><USER2> May I suggest a more mundane reason: The average german word length may be longer than English so you can fit less words in a tweet, although this SE answer as some anecdotal evidence to the contrary. [http://english.stackexchange.com/questions/2998/do-most- lang...](http://english.stackexchange.com/questions/2998/do-most-languages- need-more-space-than-english)</comment>


[How] Should I hire my brother-in-law? - <AUTHOR>

My brother-in-law graduated this past May with a CS degree from a middle-tier private university.  After an honest shot at finding a job with nothing to show for it, he's begun to hit a wall.  He's not alone, as evidenced in a slew of recent articles:
http://online.wsj.com/article/SB124181970915002009.html
http://www.mcclatchydc.com/2009/06/25/70788/recessions-toll-most-recent-college.html
I'm beginning to get worried that his hot & steamin' degree is about to get cold and soggy if he doesn't get some work experience to keep his resume moving.  He isn't as motivated as the typical entrepreneur-type on HN so I don't think he'd start his own venture by himself.
So here's where my question for HN comes in...  I've had a couple of ideas up my sleeve but no time to implement them (my day job writing HFT software has me pretty tied-up).  Do you think it's a good idea to hire my brother-in-law to kick off a venture that I otherwise wouldn't have the focus for?
If the answer is yes, how should he be paid?  Here are my concerns:
* Paid in equity - He needs some immediate pay for his efforts.  If the project fizzles out because I don't help him execute, he never gets any compensation for this.
* Paid per hour - He is very inexperienced, especially with high performance and/or web development.  Most of his hours will be spent learning.  I don't necessarily want to throw money out the window to train him on things that I would be doing for fun in his position.
* Paid per deliverable - This seems like the best bet, almost like hiring a consultant.  Am I wrong on this?
* Some hybrid of equity & hourly or deliverable - This would provide a vested interested in the venture plus offer some immediate cash.
I've specifically avoided including "experience and training" in the compensation list because I know this has a stigma on HN.  Although I do think he will be gaining some very valuable programming knowledge in this pursuit.
So, what are you thoughts? <comment><USER2> Do a trial project (but don't call it that). Say a two or three month project for $N. Tell him that's the only project you plan to do with him.

Assume you will get nothing usable in return. Write off the money as a loss. If you're pleasantly surprised with the results then do a bigger/real project with him. If not then at least there are no messy endings and hurt feelings.

<comment><AUTHOR> I like the idea of that. This way I can make sure he's capable of focus and delivery.

</comment></comment><comment><USER3> Think about some other angles too. Is he prepared to be your employee? For how long? Do you think he could take you for granted? What if it doesn't work out for one of you? How bad could it get? Are you both prepared to handle the consequences, especially on a personal level?

</comment><comment><USER4> What has he been doing besides looking for a job?

If it's been writing code, building something, then yes you should hire him.

Otherwise, go with your gut - either steer clear or pay per deliverable.

<comment><AUTHOR> Unfortunately it may be latter. I think the combo of your idea and staunch's may work. I'll give him a pay-per-deliverable quick project as a trial run and see if he just needs structure to get into it. If not, it was a gift of some money in a rough patch.</comment></comment>


Using Big Data to Estimate Consumer Surplus:  The Case of Uber - <AUTHOR> https://drive.google.com/file/d/0B3y6Efb4V73TdG9pV1F0VGpsM1E/view <comment><USER2> If you would like to listen to an entertaining version of the paper, here it is: [http://freakonomics.com/podcast/uber-economists- dream/](http://freakonomics.com/podcast/uber-economists-dream/)

<comment><USER3> Interesting that this is from the author of Freakonomics. This contains a very popular pro-Uber conclusion:

 _Inelastic demand translates into large consumer surplus estimates: roughly $2.88 billion dollars in 2015 for the four cities in our sample, or $6.76 billion if extrapolated to all UberX trips in the U.S. for that year. This estimate of consumer surplus is two times larger than the revenues received by driver-partners and six times greater than the revenue captured by Uber after the driver-partner's share is removed._

This certainly puts a different spin on accusations of price gouging with surge fees.

(Note: I have no affiliation to Uber, though I am a big fan of the service)

<comment><USER4> It's a different spin, but 'price gouging" is by definition extracting consumer surplus from those willing to pay more if necessary. The other way of spinning those figures is that if consumers spend $1 for every $2.60 they're willing to spend on Uber then Uber rides is doing an unusually efficient job of revenue maximization compared with most other businesses, particularly considering a large part of their brand value is being perceived as relatively cheap.

That's particularly the case when you consider that consumer surplus is also Uber's competitive moat against potential new entrants to the market that couldn't compete with Uber on price; as the paper's author's point out it's a _short run_ consumer surplus and the long run demand elasticity is likely to be much lower.

</comment></comment></comment><comment><USER5> The most popular consumer services usually transfer the most value from producers to consumers.

YouTube is a great example. YouTube hosts copyrighted videos and music. For most of its history, producers weren't remunerated. Even today, a great deal of user-generated content is reenacting or remixing conventional Hollywood IP.

Apple built a lot of iPhones with inexpensive overseas labor—HTC, Nokia and Motorola earlier on for that matter.

Facebook gets the vast majority of the content it shows people for free, from its own users. Crazy!

Google puts ads in front of other people's stuff. Regular search and direct navigation ads certainly don't pay producers. I assume most content on the internet took time, and therefore money, to make.

The producer-to-consumer value transfer doesn't always favor the mediator. Comcast's broadband internet was a great deal at $60/mo, considering piracy. Though in the late 90s/early 2000s people were paying for both broadband and TV—not so much the case today.

You might say, but that's all legal! Remixing copyrighted content! My tone might suggest that these business models depend on violating the law somehow. I'm just describing the facts. Facts have a well-known... bias.

Factually, a lot of popular services transfer as much as 100% of the value from producers to consumers.

Whether or not something should be illegal in there is a different question.</comment>


Ask HN: How to process a growing list of 'to reads' I do not have time to read? - <AUTHOR> I have a strong desire to read more than I have time for and am frustrated when I do not get to things that I find interesting or have time for.
Looking to see if anyone else has a similar challenge and how they deal with it.
at this point I have a text file with many links I will never get to (unless I win lottery).  I do not like using browser bookmarks as I find they get forgotten about.  With a text file I can record the link and than my thoughts on it as if it were an ongoing conversation.  Note: I have all of this in a single org-mode document.
Thank you in advance for any input! <comment><USER2> Make different priorities of reading based on what your real-life priorities are. Some things you'd better read right this moment and some things when nothing better to do, if ever. Don't fear removing marginally useful articles from your reading list: no one can read everything.

To simplify this approach skim over articles you have without reading too deep and decide what seems important: better reads tend to attract attention.

</comment><comment><USER3> I use [https://www.instapaper.com/](https://www.instapaper.com/) and then catch up at the dentist, on the train or such. It doesn't cover youtube videos or other more complex content. Most is articles between 3 minutes reading up to 120 minutes reading (very long Wikipedia articles). And it's still easy to forget about articles, I have some 2+ years old.</comment>


ProtonMail-run site with GDPR advice left user details exposed - <AUTHOR> https://www.theregister.co.uk/2020/04/29/protonmail_gdpr_advice_site_git_snafu/ <comment><AUTHOR> > _Within the /.git/ repo were the keys to GDPR.eu's WordPress kingdom: a full > and unabridged copy of wp-config.php. In a WordPress installation, wp- > config.php is the critical file containing a plaintext copy of the username > and password for the SQL database powering the entire site._</comment>


Apple rejected Flattr… and it's not the end - <AUTHOR> http://blog.flattr.net/2012/05/apple-rejected-flattr-but-its-not-the-end/

<comment> DanI-S _> We understand that directing your user outside of your app may not be the user experience you prefer to offer your users. However it is a common experience in a variety of iOS apps._

That doesn't seem like the kind of uncompromising approach to fantastic user experience that has made Apple so successful.

<comment><USER2> I think Instacast, and maybe Flattr as well, should boycott Apple and instead focus on the Android platforms starting with Google Play and Amazon's Appstore. Otherwise they are helping to perpetuate and even reward this kind of behavior.

Does anyone have the link for Instacast for Android?

<comment><USER3> Year after year, this 2003 essay by Tim Bray continues to be true:

> I've been following some discussions about the future of software > applications, and a phrase that came up in my dinner with Robb Beal has been > echoing in my mind.What it comes down to is this: if you want to develop > software, you can build for the Web and/or Unix and/or OSS platforms; or > alternatively, you can be a sharecropper. Your choice, but I think it's an > easy one. Especially since the users out there want you to do the right > thing.

> What Robb actually said, in a conversation about Mac software outputs like > Ranchero and Watson and his own Spring, was that building for the Apple OS > feels like being a sharecropper.

[http://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePla...](http://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePlace)

<comment><USER4> I think his statement of "the users want you to do the right thing" is being a bit generous. Users want whatever app they want on whatever platform they have. They don't want to jailbreak their device to install your app or go to some out of the way (possibly untrustworthy) place to locate it. Centralized, reliable app stores are liked generally by users. That said, as a developer, it is onerous/depressing to have faceless "bureaucrats" decide the fate of your apps acceptance/rejection.

<comment><USER5> Funny as a developer I don't have the same problem. I intrinsically understand that it is their store hence their rules. So long as I follow their well published and understood guidelines there won't be a problem.

Just like I would get banned from Google if I didn't follow their rules.

<comment><USER6> "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."

</comment></comment></comment></comment></comment></comment><comment><USER7> My big unanswered question going into the article was "What the crud is Flattr and why should I care." Starting your posts off with a brief introduction of who you are is often a good idea.

Flattr is a micropayment system. You pay them a monthly subscription, then Like(tm) a bunch of stuff on the internet. They split up whatever portion of your monthly sub that they don't keep among the places you tag. Apple presumably flagged the app which integrated Flattr due to their well-known policies about in-app payments.

<comment><USER8> > Starting your posts off with a brief introduction of who you are is often a > good idea.

IF most of your readers don't know what you are doing. I think this was written for their community (not HN), so most of them know what Flattr is about.

Also, they have "About Flattr" in the footer - not very prominently placed, but still find-able.

<comment><USER9> It isn't just Flattr: I encounter this issue regularly when being linked to startup blogs. Having one sentence or one link on every page that succinctly describes what you do just seems like a good idea. The web is made for linking, and not everybody will walk through the front door.

</comment></comment></comment><comment><USER10> In this case, where donations would happen with one tap, I think it is sensible for Apple to require breaking the UX so as to avoid unintended donations by the users, or malicious implementation by the developers.

<comment><USER11> I'm not very big on Apple practices, but I have to agree with you here. This seems like the sort of tool that can be used to do some really shady things. Which, in and of itself, is not a problem. The thing is, when money 'goes missing' from user accounts, they tend to blame either Apple or the App company as opposed to themselves for not paying attention to what they were doing. Apple has been burned in the media by things like that before. IE - Kids racking up thousands of dollars of purchases because mom authorized one, and then let the kid go play on her ipad.

In this case, this seems reasonable. Unless I'm missing something, this is not the sort of thing you want being easy for novice users.

<comment><USER12> I think you missed the point that you set a fixed amount of money to use each month. There's no way flattr will use more than the chosen monthly amount.

<comment><USER11> Principle is the same. So Flattr only enables shady access to $30 a month, which mom wanted to use at a day spa say. Only little suzy saw the "like" thing and said, "Hey... I like this paperdolls app/site (whatever)!"

I mean, mom may have even been happy allocating some money to educational things, but not virtual Barbies. Your statement is basically saying, "Well Flattr only enables shady people to steal a set amount every month."

<comment><USER13> Explain to me, exactly, step-by-step. How forcing little suzy to click 2 times by having to use safari, instead of 1 click inside the app. Would stop the problem you're mentioning.

You're confusing two completely separate things. One is preventing fraud (what you think apple is doing). The other is force a possible fraud to take 2 seconds longer (what they actually are accomplishing). They have the same amount of control to prevent fraud within the app as within safari. If they want to prevent fraud, they could ban fraudulent apps. Not just add unnecessary roadblocks to apps that just happen to not be paying them app store share for donations.

<comment><USER5> You seem to think that 1 click is no different from 2 clicks.

I draw your attention to Amazon's one click patent and the huge influence it has had on their success. 1 click can be reactive. 2 clicks almost always requires you to think about your decision.

<comment><USER14> _Explain to me, exactly, step-by-step. How forcing little suzy to click 2 times by having to use safari, instead of 1 click inside the app. Would stop the problem you're mentioning._

You'd make an awesome politician: Can't answer the question? No problem! Ask yourself a different question and proceeed to answer that one instead!

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> "We understand that directing your user outside of your app may not be the user experience you prefer to offer your users. However it is a common experience in a variety of iOS apps."

So... it's crappy for everyone across the board. Take comfort in that!

<comment><USER16> Except for apps that pay 30% to Apple. That's a key distinction.

</comment></comment><comment><AUTHOR> Here is a copy (as PDF) of the article in case you can't access the site:

<http://christian-kienle.de/ShinyVideo/Flattr.pdf>

</comment><comment><USER17> I think we can safely say Apple has dropped their party manners and shown the knives.

Unfortunately android is the only possible competitor I see, and the carriers have pretty much guaranteed that android won't be any freer for users or developers.

</comment><comment><USER18> I'll wait this one out to see if the issue snowballs. Either way, this could turn out to be a positive PR tactic. God luck to the flattr team.

</comment><comment><USER19> I think we DDoS'd them.

<comment><USER20> considered brokep from the pirate bay is heavily involved in flattr, i'm a little bit disappointed the site went down

<comment><USER21> That is the exact thing that crossed my mind. brokep Peter Sunde is not only heavily involved, he is the founder.

</comment></comment></comment><comment><USER22> I hope they planned for this. Hinging an entire business on the decision of a 3rd party is Russian roulette.

<comment><USER23> Flattr is fundamentally a web company, competing with Google's +1 button and Facebook's Like button more than than Paypal donations, even if users _are_ spending real money. This is just a potential new arena for Flattr, and not their core business.

</comment></comment><comment><USER24> Unlucky you have been curtailed by Apple for now but sure you can rework your model to fit within what is allowable. Keep persevering as you seem to have built a useful application.

<comment><USER25> Thanks, as said in the post - we'll keep at it as the only way to find out what's cool with Apple and what's not is to submit stuff to them and hope to have a constructive dialog.

</comment></comment><comment><USER26> OT design suggestion: when you have a corporate blog, have a prominent link somewhere on the top that goes to your main site.

</comment><comment><USER27> Rejected by Apple and the 'Paypal suxx' on their desk. Tough luck

</comment><comment><USER16> Would the app have been approved if Apple was given 30% of the proceeds? I am guessing yes.

<comment><USER5> Would the app have been approved if they had followed Apple's guidelines? I am guessing yes.

<comment><USER28> Isn't that the same thing?</comment></comment></comment>