We are currently building a framework (closed source static library) that will communicate with some Smart home devices via Wi-Fi. This framework will be used by 3rd party developer to build their own applications (mainly mobile application) in order to communicate with those devices.Currently, we have split opinions on if the framework should generate any visible logs (say a log file, or event logger) on a release version (we will supply a debug and a release version to 3rd party developers).Reasons to have logs:Logs are always helpful if we need to find out the root cause of unexpected error.Any form of logs is always goodGetting the logs information from mobile phone should be easy. (By app user or support desk technician)We can prove it is application developers' fault if they blame it to us.Some issues may only happen in production that cannot be reproduce on test environment.Log files are not big anyway. A small log file that use some of the device storage shouldn't be an issue.All servers application/API always have logs.Reverse engineer is always possible via decompile, so it shouldn't really matters.Reasons to not have logs:Framework doesn't own the application. Most users have no idea how to get the log files out of application's storage (hence less likely to be able to get it), so don't add something that will not be usedApplication developer should be able to pinpoint the problem by their own logs/debug method before coming to usRisk of exposing too much information to end users.No other frameworks seems to do it (e.g. Facebook SDK/Google SDK)Taking up device storage. Every byte count.It is the responsible of the framework user (developer) to have their own logs/crash reporting if they want to.Debug version with console/debugger logs should be enough for developers.So basically we are not able to get into an agreement. Just wondering what does the wider community think about this if you are the developer that use a closed source static library on a client application.
Framework logs on client application
android;ios;logging;third party libraries