Code for saving / loading a class object
Why saving reference to Context and then create SharedPreferences each time? There's duplicate code for creating SharedPreferences You could just use context in constructor to create member SharedPreferences to use in your methods. If you want to keep it as it is, at least extract duplicate code into separate method.
I am missing null checks. I expect to get very obscure behaviour when passing null for keys or classes. Test for null and throw NullPointerException early, be fail-fast. For example checkNotNull or some NotNull annotation to help better fighting against null. Another way to fight is to use kotlin, which doesn't allow null on compiler level unless you make variable optional.
I don't like that gson is private and static.


That means there is no way to configure gson. Would be better if this was member property and I would be able to pass different configuration of gson. Can add consructor overloads for that. Maybe this is overdoing it for your case, but I usually configure Gson quite a lot, have my own TypeAdapters and I wouldn't be able to use my Gson configuration with your class.
At first I was concerned about thread-safety Gson is thread-safe, so there's no argument against static in this sense. Always check for that when you make something static like this.

Pretty sure that when saving preferences in android, you first put key and then value. Your saveObject has it the other way around, that is imho confusing. I'd switch parameters in loadObject too so that key is always first in those cases, but guess that's a bit subjective.
Immutability makes code simpler to use and read. If something is final, you don't need to keep be alert if it changed anytime. context member variable can be final and all method parameters can be final too. After refactoring possible SharedPreferences and Gson instances can also be final - set in constructor.