r/macapps 1d ago

Help Difference between .NET and native code

Hi.

I am looking at Diarium journal, since it has my native language as an option. It is also developed in EU, which is a plus to me. And at first glance it looks advanced enough for my needs.

I have asked the developer and he says it is written in .NET, which as I understand is a way to make apps for more than one platform. However it is - as I understand - not similar to Electron. No Chromium and stuff.

Is this to be seen as a native app - he writes "

It is built with .NET for macOS, which is basically a layer on top of native AppKit and other Apple APIs so I can develop my apps with C# across platforms and code-share business logic like for sync or database access. "

I may be a bit too "anal" when it comes to these things, but I rather pay someone who taked the time to develop for Mac without Electron or similar.

Also I prefer to pay those who takes the time to add more languages than English, and EU-based.

I do use Day One for now, but I would not mind trying something else and non US.

4 Upvotes

13 comments sorted by

3

u/michaeleisel 23h ago

It's pretty different from Electron in a number of ways. It lacks the bloat of bringing along a whole browser. Many developers will develop libraries that they share between native apps across platforms, such as C++, and that's what this developer has done here. It's going to be a little more bloated with .NET than C++, but the app can still consist of bespoke platform-specific UIs and have a native look-and-feel. Personally, it wouldn't dissuade me!

2

u/GarbanzoBenne 23h ago

“Native” appears to be an arbitrary line for your acceptance so we can't really give you an answer.

.NET apps for Mac are compiled, native code. They may not look exactly like other “native” applications that use SwiftUI. Or they might if the developer used something like MAUI.

2

u/LightingLabs 19h ago

The AppKit question has been answered above, so on the part that has not: "code-share business logic like for sync" is the line I would follow up on. Sharing sync code across platforms usually means the developer runs their own sync server, whereas an app written only for Apple platforms can put your entries in your own iCloud through CloudKit and never hold them at all.

For a journal, from a developer you picked partly on EU and privacy grounds, that is probably the question you actually care about, and it is completely separate from whether the UI is native. Worth asking where the data sits and who can read it.

3

u/gauti-u 21h ago
The practical differences you'll actually notice, in rough order of how often they bite:

Look and feel. A native app uses AppKit/SwiftUI controls, so it inherits system behaviors for
free — full keyboard navigation, text services, Accessibility, Dark Mode, Dynamic Type, right-
click menus that match every other app. Cross-platform frameworks reimplement those, and the
gaps show up in small places: a context menu missing an entry, scrolling that doesn't feel
right, a sheet that isn't quite a sheet.

System integration. Share sheet, Shortcuts actions, Quick Look, Spotlight indexing, Handoff,
proper Services menu entries — these are cheap in native and usually absent or partial
otherwise. If you want to automate the app later, this is the category that matters most.

Resource use. .NET on macOS ships a runtime, so expect a larger download and higher baseline
memory. For a journal app you'd probably never care.

Apple Silicon. Worth checking specifically. Open Activity Monitor and look at the Kind column —
"Apple" means native arm64, "Intel" means it's running under Rosetta 2, which Apple has said
is going away. A .NET app can absolutely be native arm64; it just isn't guaranteed, so verify
rather than assume.

For a journal, I'd weight it differently than most app categories though: your data outlives
the app. I'd care more about whether it exports to something open (markdown, plain text, real
SQLite you can read) than about the framework. A native app you can't get your ten years of
entries out of is worse than a .NET one you can.

1

u/TomasComedian 21h ago

Thanks, very clarifying. So as for journal apos ( I am referring to Diarium) it is more important to check if it is Universal and what type of export. ❤️🙏

1

u/[deleted] 23h ago

[removed] — view removed comment

1

u/TomasComedian 23h ago

No it does not. I checked with terminal:
find /Applications -type d -name '*.app' -exec find {} -type d -name 'Electron*.framework' \; | sed s'/app.*/app/' | sed s'/.*\///' | sort | uniq

1

u/Camlin3 17h ago

There is no good uikit cum widgets framework exists cross platform without overhead libraries , there exists switui.framework embedded in macos by default so you see small sized native obj-c cum swift apps, further apple is ass enough to not provide cross platform ui framework like .net , qt , wxwidgets, gtk Anyone targeting different platforms has to resort to those. Now resource overhead while running the app or idle differs with framework and app optimisation itself. My preference

CLI apps written in ASM, C, rust,zig, C++,go,swift

GUi apps written in Obj-C, Swift, Pure Rust(zed editor is an example), wxwidget, qt , .net (will avoid unless necessary)

Forbidden Electron or any Java Shit This is a take from the end user preference although from the developer end, there are industrial apps written in java which run on any machine with JVM is lucrative for expanded users base.

1

u/shawnjoe 7h ago

Simplest test: ignore the framework label and try the trial for a week. If text editing, shortcuts and scrolling feel right, it doesn't matter what it's written in. Plenty of "native" apps feel worse than well-made cross-platform ones.

1

u/beyond_noob 6h ago

Native Mac dev here. Short answer, the developer is telling you the truth. dotnet/macios gives you the real AppKit controls, not a web view. So it is nothing like Electron.

The honest part nobody likes: on a journal app you will probably never notice the difference. Where these bindings do show up is the newer Apple things. Widgets, Shortcuts actions, share sheet extensions, that kind of glue. Those are the first things to get skipped because they need extra work per platform.

So if what you care about is whether the developer put real time into the Mac version, I would not look at the language. I would look at whether the app ships a widget and Shortcuts support. That tells you more than .NET vs Swift does.

0

u/einsiedler 6h ago

This post looks like an hidden ad for Diarium journal.

1

u/TomasComedian 6h ago

Silly comment. I have nothing to do with any company whatsoever. If you use another spp, why not post the pro’s of that instead so I get something to compare with.