Make properties be backwards compatible with the original ObjC API

[crazytonyli]

Description

@jkmassel raised a concern regarding changing the null_unspecified Objective-C properties to nullable, that since we may need a while to finish the translation from Objective-C to Swift, the apps will need to make lots of code changes (potentially repeatedly) to adopt the new API if we release new versions of WordPressKit for minor fixes. We agreed to keep the model properties backwards compatible with the original API, and create a long running branch for the Objective-C to Swift translation work.

There are three related PRs that were merged into trunk: #556, #557, and #558. They translated following models to Swift:

• RemoteBlog.swift from RemoteBlog.h
• RemoteMenu.swift from RemoteMenu.h
• RemoteMenuItem.swift from RemoteMenuItem.h
• RemoteMenuLocation.swift from RemoteMenuLocation.h
• RemoteReaderSite.swift from RemoteReaderSite.h
• RemoteReaderSiteInfo.swift from RemoteReaderSiteInfo.h
• RemoteReaderTopic.swift from RemoteReaderTopic.h

This PR reverts most of above model's properties back to Implicitly Unwrapped Optionals (as declared in their original Objective-C interface), except RemoteMenu, RemoteMenuItem, and RemoteMenuLocation since their original Objective-C interface declares their properties as all nullable.

Testing Details

I think we are all good as long as CI jobs are green.

• Please check here if your pull request includes additional test coverage.
• I have considered updating the version in the .podspec file.

[crazytonyli]

The two properties above are kept as Optional since we know for sure that they are:

WordPressKit-iOS/WordPressKit/RemoteReaderSiteInfo.swift

Lines 123 to 135 in 1baed48

	class func postSubscription(forSubscription subscription: NSDictionary) -> RemoteReaderSiteInfoSubscriptionPost? {
	guard subscription.wp_isValidObject() else {
	return nil
	}
	guard let deliveryMethod = subscription[SubscriptionDeliveryMethodsKey] as? [String: Any],
	let method = deliveryMethod[DeliveryMethodNotificationKey] as? [String: Any]
	else {
	return nil
	}
	return RemoteReaderSiteInfoSubscriptionPost(dictionary: method)
	}

WordPressKit-iOS/WordPressKit/RemoteReaderSiteInfo.swift

Lines 141 to 153 in 1baed48

	class func emailSubscription(forSubscription subscription: NSDictionary) -> RemoteReaderSiteInfoSubscriptionEmail? {
	guard subscription.wp_isValidObject() else {
	return nil
	}
	guard let delieveryMethod = subscription[SubscriptionDeliveryMethodsKey] as? [String: Any],
	let method = delieveryMethod[DeliveryMethodEmailKey] as? [String: Any]
	else {
	return nil
	}
	return RemoteReaderSiteInfoSubscriptionEmail(dictionary: method)
	}

[jkmassel]

One nit we should address, but then I think this should be good to go

[jkmassel]

If I'm not mistaken, this would be an un-breaking change, so we could probably move this out of the Breaking Changes section (and thus avoid cutting a new major version unnecessarily?)

[crazytonyli]

Technically speaking, I'd argue they are still breaking changes, even if we revert the two properties changes I mentioned above. The types are changed from Objective-C classes to Swift classes. And Swift class has its restrictions that Objective-C class don't have, like they cann't be inherited by an Objective-C class. I guess it's not likely that the apps have a subclass of these model types, but I'd say it's best to follow semantic version strictly, what do you think?

[crazytonyli]

@jkmassel I'm going to merge this PR for now so that I can create the new dedicated Swift migration branch and change the open PRs to target the new branch. I'm happy to address further comments if you have more questions 🙂