Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming

Apple Now Rejects Electron Apps from Mac App Store (david.dev) 124

Posted by msmash from the PSA dept.
Mac developers are reporting that apps made using Electron (which is a framework that allows companies to ship web apps in a native app wrapper) are now being rejected by the automated Mac App Store review process. From a report: The apps in question are getting flagged because of their usage of private API calls. These API calls are not in the app itself, but part of the underlying Electron framework. The detected private API symbols include:" CAContext CALayerHost NSAccessibilityRemoteUIElement NSNextStepFrame NSThemeFrame NSURLFileTypeMappings." Apparently, the Electron framework has used these APIs for years. What has happened is that Apple has upgraded its server-side app review processes to detect more violations of its App Review guidelines, and now this private API usage is being identified. Individual Electron app makers are a bit helpless as the issue can only really be fixed by pushing changes in the Electron code itself. It does not appear that Electron is doing anything extreme, certainly nothing malicious. App Review doesn't care about why an app is using private API, it's a hard and fast rule (at least in theory).
This discussion has been archived. No new comments can be posted.

Apple Now Rejects Electron Apps from Mac App Store More

Apple Now Rejects Electron Apps from Mac App Store

Comments Filter:

  • Good (Score:5, Insightful)

    by thereddaikon ( 5795246 ) on Monday November 04, 2019 @11:49AM (#59379284)

    This generation of developers should learn how to write proper programs, not glorified webpages that hog resources and increase attack surface.

    • This generation of developers should learn how to write proper programs, not glorified webpages

      What's the non-web API to give "proper programs" a graphical user interface across all popular desktop and mobile operating systems? Is Qt still the best practice to reach users of Windows, macOS, X11/Linux, Android, and iOS without inflating costs fivefold?

      • Because you can doesn't mean you should.

        • Re: (Score:2)

          by tepples ( 727027 )

          I'm having trouble discerning the intent of your laconic statement. Please clarify. Are you calling it good practice to turn prospective users away with "Sorry! This application is not available for your operating system"?

          • The trouble is, once they've got a cross-platform offering in place, most people won't care or understand it's inevitably a half-assed UX. But that doesn't seem to be something Apple should regulate. It self-regulates.

      • Re:What common API? (Score:5, Insightful)

        by omnichad ( 1198475 ) on Monday November 04, 2019 @12:14PM (#59379472) Homepage

        What's the non-web API to give "proper programs" a graphical user interface across all popular desktop and mobile operating systems

        A web site. You literally don't need an app in this case.

        • You literally don't need an app in this case.

          An application implemented as script on a website cannot interact with with platform features that browsers do not yet expose to script. And whenever a browser publisher proposes exposing such features, such as Web Bluetooth [slashdot.org] and the Native File System API coming to Chrome [slashdot.org], there's a huge uproar on Slashdot that websites ought not to have access to these features.

          • yeah, don't use a web app that allows this access, install a native app instead that allows this access.

            don't know if you realize how stupid that sounds.

            • Wow man... Many application are written in Electron and work well. This is a very narrow view and doesn't even take into account that just because an application is built with HTML and JS components doesn't make it a "web app". And what's so stupid about not wanting to do the same work to replicate the same experience on multiple platforms? What is the down side?

              • i was being sarcastic. read the thread.

              • And what's so stupid about not wanting to do the same work to replicate the same experience on multiple platforms? What is the down side?

                First, a cross-platform application will never optimal experience on all platforms.

                Second, if a seat of a license for a proprietary application or the peripheral required to use that application costs more than an entry-level computer, you can bundle an entry-level computer with the application. For example, the developer of a peripheral to turn an iPad into a cash register can go iPadOS-exclusive and include the price of a base model iPad in the advertised total cost of ownership.

            • Re: (Score:2)

              by tepples ( 727027 )

              There are people who think JavaScript web apps should never have existed, that the web is for static documents and form-driven web apps and the OS's package manager is for applications.

        • Comment removed based on user account deletion

          • The most famous Electron app is Atom

            Please tell me you're not holding up Atom as some shining example. The thing is so buggy that I gave up on it almost immediately. I don't care about bloat in a text editor - I care about speed and efficiency and the thing just working right when I need it to. Maybe that's not because of Electron.

            That's not the problem here nor what I'm even referring to. The problem is that every business wants to have an "app." They don't know why they want an app. They don't offer functionality, just content. So th

            • Re: (Score:2)

              by tepples ( 727027 )

              I don't care about bloat in a text editor - I care about speed and efficiency

              Once you start thrashing swap, bloat saps your "speed and efficiency".

          • >The most famous Electron app is Atom

            No, the most famous electron app is called "circling in a quantum probability wave around the nucleus". It's been popular in this universe since a few seconds after the big bang.

          • sure, we could write programs more efficiently, but we don't, and the truth is there's no evidence that Electron applications are particularly bad here

            HexChat, a client for the standard Internet Relay Chat protocol, uses one-tenth the RAM of the official desktop app for Skype, Slack, or Discord. As far as I'm aware, the biggest advantage of using Skype, Slack, or Discord for text chat instead of IRC is not having to pay for a VPS to run a bouncer to log your channels.

      • Qt, although I can't speak to cost increases. Because WASM now exists, it's even arguably a better end result for everyone, including the developer who can now share app code in much the same way.

      • Re: (Score:2)

        by darkain ( 749283 )

        Considering the most popular Electron app is VS Code, and its main competitor is SublimeText which also works on every major OS WITHOUT being bloated? Yeah, there are alternatives. If a single dev can do it, why can't hordes of developers all working together?

    • Comment removed based on user account deletion

      • Why would you say that? Someone might consider their simple app taking longer to load and using more resources than a 90’s operating system to be a FEATURE. /s

      • Re: (Score:2)

        by tepples ( 727027 )

        In "native", what is the name of the call to open a window?

        • Why are you trying to open a window in a platform that doesn’t use windows?

          • Re: (Score:2)

            by tepples ( 727027 )

            Why are you trying to open a window in a platform that doesn’t use windows?

            I was using "a window" in a broad sense to also include a full-screen activity, as seen in iOS, iPadOS, and Android. These senses would be comparable to a "maximized window" on Windows, macOS, or X11/Linux. And even with "window" in the narrow sense of occupying a proper subset of the display, the multitasking features of iPadOS (Slide Over and Split View) and Android 7 and later for tablets (multi-window mode) can run an application in a window, much like Windows, macOS, or X11/Linux.

            So let me rephrase: In

        • new JWindow().setVisible(true);
          Works on basically every platform, but I guess that was not what you where seeking.

          • Re: (Score:2)

            by tepples ( 727027 )

            I know JWindow is available in the Swing library that comes with OpenJDK for Windows, macOS, and X11/Linux. But is a library available for iPadOS and Android to implement the JWindow class? If so, which?

            • Actually yes, you can run Swing on Android, and there are some weird projects of iOS, too, like Avian VM. BU in the later case i doubt they ported Swing. There are some attempts to port the new Java GUI library, JavaFX (has nothing to do with the JavaScript like programming language with the same name).

    • Web pages are actually pretty efficient. Ad networks are not.

      • Re: (Score:3)

        by ceoyoyo ( 59147 )

        Electron is not efficient.

        • I suppose it depends what metric we're considering efficiency of.
          At it's core, it's V8- which in terms of execution cycle overhead, is pretty fucking efficient as far as language VMs go.
          Blows python out of the water with a nuclear torpedo, that's for sure. Perhaps we should ditch that, too?

          • Re: (Score:2)

            by ceoyoyo ( 59147 )

            Yeah, I'm not sure why Electron is such a pig. It shouldn't be, but it is. V8 itself is pretty good, although javascript does seem to lend itself to misuse.

            Anybody who writes anything computationally intensive in Python is doing it wrong. Python's greatest strength is the collection of efficient compiled computational libraries, and a bunch of ways to very easily write your own if necessary.

            • I haven't noticed that it's a pig. I mean nodejs definitely lends itself to the same cancer that Python does- people include libraries of dubious quality until your script has 850,000 dependencies and takes 45 seconds to start up, so there's that going against it.
              But I use a couple of lightweight Electron apps, and they're snappy as hell.
              Sure, they have a pretty large overhead in shared libraries... But then again, doesn't everything these days? I mean hell, gnome-terminal requires about 800MB of resident
      • Web pages are semi-efficient for storage, but of course there are no memory or cpu efficient web browsers to display them with. The original Mac with 128k of memory could display styled text in multiple fonts. The extra gigabytes of memory and multiple processes of modern browsers havenâ(TM)t really improved things as much as you might think.

        • Re: (Score:2)

          by epine ( 68316 )

          The original Mac with 128k of memory could display styled text in multiple fonts.

          The original Mac with 512 kB of memory effectively swapped to floppy disk to access resource forks of the different programs you were running at the same time (meaning cooperatively, not preemptively, an insanely great technology which eluded Apple for seventeen long years—ahh, sweet seventeen, and only yesterday you were a twinkle in my eye).

          Since you couldn't really fit two large programs on the same floppy disk, every

    • How would using a web based "framework" increase the attack surface on my Mac?
      The only way would be a backdoor in the framework, and that has nothing to do with "web technology" or anything else.

  • You have to wonder why these are being used (Score:3)

    by SuperKendall ( 25149 ) on Monday November 04, 2019 @11:50AM (#59379290)

    The interesting thing to me is, why is a cross-platform framework like Electron even using these API's?

    The UI's they preset are less, not, complex than most native apps. It would have taken extra work to even find these other calls to use, than to simply use the UI frameworks that are there... how did these end up being used?

    • Re: (Score:2)

      by Altus ( 1034 )

      Probably allowing for some interaction between the web page and the device itself, possibly in ways that browsers would not allow. Still that list is weird, it does look more like layout presentation layer stuff. CAContext CALayerHost NSAccessibilityRemoteUIElement all sound like iOS draw code. The other stuff I am not so sure about.

      • The Electron Framework is written in C/C++/Objective C.
        It can access anything it wants without using "private" APIs.

    • Re: (Score:2)

      by MagicMike ( 7992 )

      Electron is bundling chunks of Chromium I think, and they are using it to do partial frame updates in order to increase performance without spinning up your fans. They are using those APIs because apparently macOS doesn't provide APIs to update part of a frame. Mozilla wrote up a good article on it as they just implemented it in Firefox (though I guess they might revert that!)

  • The less web site disguised as an app the better

  • NSA??? (Score:4, Interesting)

    by ls671 ( 1122017 ) on Monday November 04, 2019 @12:00PM (#59379360) Homepage

    The detected private API symbols include:" CAContext CALayerHost NSAccessibilityRemoteUIElement NSNextStepFrame NSThemeFrame NSURLFileTypeMappings."

    NSAccessibilityRemoteUIElement sure looks reassuring to me. What a clever name choice! :)

    • I assume you are joking, but in case you aren't - why in the world would you think the NSA would require anything built into the system to access it. Their baseline job is to break into systems that are designed to prevent it by actual bad actors with real technical means. These weenie apps are security sieves, script kiddies stuff, by comparison.

      • why in the world would you think the NSA would require anything built into the system to access it

        It may have to do with the _NSAKEY variable in Windows NT 4 [wikipedia.org], allegedly used to facilitate review of the cryptography code in Windows by U.S. export control authorities, and the 24-bit NSA "workload reduction factor" key used by old versions of Lotus Notes [wikipedia.org].

        But here, the NS stands for "NeXTSTEP", the old name for the Cocoa API in macOS.

    • Re: (Score:2)

      by Arkham ( 10779 )

      I assume this is a joke, but for anyone who doesn't know:

          NSAccessibilityRemoteUIElement = NextStep Accessibility Remote UI Element

      NextStep was API layer for the NeXT OS that Apple bought as the basis for macOS (and now all the other OS's Apple has).

      • Re: (Score:2)

        by ls671 ( 1122017 )

        So, then:
        NSNextStepFrame == NextStep NextStep Frame

        Thanks a lot for the insight, it makes perfect sense!

        They sure have very clever names! :)

        The detected private API symbols include:" CAContext CALayerHost NSAccessibilityRemoteUIElement NSNextStepFrame NSThemeFrame NSURLFileTypeMappings."

        • Re: (Score:2)

          by dissy ( 172727 )

          If you insist that is the case, then what does the word "ccessibility" mean?

          There seems to be no record of this word you made up, and google only returns millions of pages that say you're not able to spell correctly...

          • Re: (Score:2)

            by ls671 ( 1122017 )

            Actually, I find "NextStep NextStep Frame" funnier!

            More seriously, NSNextStepFrame might mean that NS doesn't refer to NextStep but to NeXT-Sun since "NeXT-Sun NeXTStep Frame" would be less redundant and would make more sense anyway.
            https://en.wikipedia.org/wiki/... [wikipedia.org]

    • Re: (Score:3, Informative)

      by 0100010001010011 ( 652467 )

      The original code for the Cocoa frameworks came from the NeXTSTEP libraries Foundation and AppKit (those names are still used by Apple's Cocoa frameworks), and the NextStep engineers chose to prefix their symbols with NS.

      Because Objective-C is an extension of C and thus doesn't have namespaces like in C++, symbols must be prefixed with a unique prefix so that they don't collide. This is particularly important for symbols defined in a framework.

      If you are writing an application, such that your code is only likely ever to use your symbols, you don't have to worry about this. But if you're writing a framework or library for others' use, you should also prefix your symbols with a unique prefix. CocoaDev has a page where many developers in the Cocoa community have listed their "chosen" prefixes. You may also find this SO discussion helpful.

    • To expand on "I assume you are joking, but in case you aren't" below... OSX is full of NSSomethingOrAnother classes because it's derived from NextStep, it's got nothing to do with the NSA being inside your mac.

      "goto fail", on the other hand...

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Monday November 04, 2019 @12:09PM (#59379438)
    Comment removed based on user account deletion

    • Re: (Score:3)

      by ceoyoyo ( 59147 )

      They've also been very clear that private framework calls are not permitted.

      Apple isn't unique in this. Relying on undocumented behaviour in any API is asking for unexpected trouble in the future.

      • They've also been very clear that private framework calls are not permitted.

        Apple isn't unique in this. Relying on undocumented behaviour in any API is asking for unexpected trouble in the future.

        Apple learned the hard way, way back in the Apple ][ days, that allowing third-party Devs. to use undocumented Calls was a Very Bad Thing(tm), and as early as the Apple ][ ProDOS days, at least warned Devs. that if they used an undocumented Call, they could expect it to be moved, renamed, or simply deleted at any time, and without notice.

        They did this for a very good reason: The use of undocumented calls and Entry-Points in the Apple ][ ROMs had become so rampant, that Apple found it nearly impossible to up

        • Re: (Score:2)

          by dissy ( 172727 )

          The change to ProDOS at the time was huge, as not only did you get speed increases and less memory usage from better code, but throwing away the spaghetti JMPs littered around DOS 3 for the same reason.

          Unlike the difficult to update boot roms, the disk system was at least able to be thrown completely out and started over.

          This was the first they added a properly documented API between ProDOS and Basic, such that versions of each were more or less interchangeable on disk. (ProDOS had minimum version requirem

      • To keep the language clean:
        Undocumented features are not part of the API, aka "interface" they are random functions that a random C-library is exporting/exposing.

    • Re: (Score:2)

      by MagicMike ( 7992 )

      Oh no! That means I can't use 90+% of their public API then!

      </cynicism> - I'm just so tired of seeing auto-generated useless API docs when I hunt for one of their symbols then resorting to stack overflow. Don't actually use undocumented APIs kids.

    • then it would be every so helpful if they had access to function calls you didn't.

      Microsoft used to do this, and I fondly remember pawing through the "Windows Black Book" (I might be getting the name wrong, been 20 years+ since I did win32 programming) and finding a wealth of undocumented calls that would noticeably improve the stability and performance of your application.

      I mean, didn't you ever wonder why Microsoft's products were always better unless they were up against assembly programmers?

  • And instantly, nothing of value was lost from the Mac App Store.

  • Blaming others for your crap API security, are we?

    Of course I still applaud anything that murders Electron with a vengence. And fire.
    In this case, the enemy of my enemy it my enemy I hate less.

  • The APIs in question are apparently for doing partial updates in a frame, so as not to use too much power.

    Firefox wrote up how and why they use them: https://mozillagfx.wordpress.c... [wordpress.com]

    Chromium uses them as well, which is likely how they end up bundled into Electron https://github.com/electron/el... [github.com]

    This seems like something where Apple may actually have to relent here, until they have an API for partial compositing?

    • Re: (Score:2)

      by rlwinm ( 6158720 )
      iOS is just bad as a platform. I've written native apps for both platforms. I don't mind Objective-C (and would take it over Java) but I sure do mind the iOS frameworks. Android has a far more sound (and powerful) architecture. Also the way iOS manages certificates is crazy. In general I dread having to touch anything on iOS. Oh, and it means using MacOS as a development platform too. Ick. Android I can do on my Linux laptop. Another guy can use his Windows machine. A third guy here does use a Mac. For iOS

      • Re: (Score:2)

        by MagicMike ( 7992 )

        I wrote this up, works well for me https://askubuntu.com/question... [askubuntu.com] :-)

        Also, fastlane at least makes certificate handling just really really irritating as opposed to fully impossible

        In general though, agreed. Working so hard to support what by my stats is just 20% of my users is really frustrating.

        • Re: (Score:1)

          by rlwinm ( 6158720 )
          So we do have a few hackintosh VMs. But the problem is we don't want to build on those for legal reasons. Or rather, more specifically, to avoid the wrath of Tim Cook should they ever find out. Since Apple is judge, jury, and executioner when it comes to supporting your application on iOS we'd rather follow the official play book. It's sad that they won't make life easier on developers.

          For the record I don't expect to see Tim Cook dancing around like monkey boy screaming 'developers' but at least give us
  • If Apple Apps use them, but they disallow outsiders, then that is monopolistic behavior that could be illegal.

Slashdot Top Deals

"To take a significant step forward, you must make a series of finite improvements." -- Donald J. Atwood, General Motors

Close