Migration guide in Readme. Should everyone migrate to OSLog?

[lolgear]

New Issue Checklist

• I have read and understood the CONTRIBUTING guide
• I have read the Documentation or CocoaDocs
• I have searched for a similar issue in the project and found none

Issue Info

Info	Value
Platform Name	e.g. ios / osx / tvos / watchos
Platform Version	e.g. 8.0
CocoaLumberjack Version	e.g. 2.3.0
Integration Method	e.g. carthage / cocoapods / manually
Xcode Version	e.g. Xcode 7.3
Repro rate	e.g. all the time (100%) / sometimes x% / only once
Demo project link	e.g. link to a demo project that highlights the issue

Issue Description and Steps

This project was very good for many years, it was de-facto a standard framework for logging in iOS (and Apple ecosystem?).
But time goes by and, well, we should, at least, add migration guide to Readme.
First section should be "Why" this framework exists and "When" you can use it.
And only after these questions we can said:
If you still want to use this framework, well, that is how you can install it.

[ffried]

Well, OSLog is nice until you need to actually do something with the logs. Ever tried to attach them to a support request created by the user inside an app? Or export them, when the user writes to your hotline and says something is not working?

Since iOS 15 (and we have a lot of users that still need to support OS' before that), it's at least possible to retrieve log entries. But not the whole archive. Apple itself recommends having an existing log infrastructure set up:
https://developer.apple.com/forums/thread/677068?answerId=684250022#684250022

Furthermore, OSLog doesn't persist logs below a certain level. And there's no way for an app to dynamically enable it. You need to install a configuration profile that does so - you can imagine the amount of work necessary to explain this to users that don't have at least some technical knowledge.

OSLog is all sweet and nice if you just need to log some messages to show up in Xcode. Also, it works reasonably well (except for the dynamic level changing) on macOS, where you could access the log store since 10.15 (https://developer.apple.com/forums/thread/650843?answerId=668567022#668567022).

But it's still some big steps away from being a replacement for a proper logging infrastructure. Also, it doesn't work on Linux. So if your writing Swift packages, that run on both Darwin and Linux platforms, you won't be using OSLog (directly) - or you'll write lots of #if os(Linux) LinuxLog #else OSLog #endif.
swift-log solves this nicely by decoupling the frontend (log message creation) from the backend (log message writing / persisting). But even though they have some kind of multiplexing backend, it really works best with a single backend. And this is still a nice place for CocoaLumberjack to exist. Because multiplexing to various loggers is what it does best - on Darwin platforms. That way you can create multi-platform packages without needing the know the logging-backend. You just write your log messages. If your package ends up in an app, it'll for example use CocoaLumberjack as backend. If your package ends up on Linux, you use whatever log backend exists there, for example the one that comes with Vapor.

---

Long story short: It's a long way from being able to fully replace CocoaLumberjack with OSLog, since there's a lot that OSLog can't (and likely won't) do: remote logging, custom log formatting, structured logging, ...

[ffried]

Btw. since OSLog (at the moment) can't really be wrapped - due to it's static evaluation of message templates - it's not something the OpenSource community can solve.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still an issue, please make sure it is up to date and if so, add a comment that this is still an issue to keep it open. Thank you for your contributions.

[Howard-Flipped]

I'm looking for the right logging framework. Indeed, as the author says, many functions such as remote logging and other functions Apple certainly will not do, for the sake of so-called security. It has always been so, giving us less and less information. We can only develop the features we need ourselves.