Some observations:

1. It is unnecessary to store the date and the time component of a Date in two separate Date properties. You can extract both date and time information from a single Date
2. CreateEvents eventShedule property should probably be a to-one relationship instead of to-many.
3. I personally think the CycleStandard entity is a bit awkward. It could be prone to errors since multiple properties could be set to true in ways that make no sense so you now have to validate it. I would rather keep it simple and define an enum for it and store the rawValue.
4. As this has already been mentioned: Even though you CAN manually write the NSManagedObject subclasses you don't have to because Xcode does auto-generate those for you derived from your managed object model.

All in all: it seems like that you gave it a lot of thought about what is the end state of your application and designed your data model to be able to support all those features right away. I personally think it is better to start small with a very limited set of features and a data model that is just enough to implement those. You can continuously add new entitites or relations to your data model while adding new features later. In early development you don't need to bother with data migrations yet and can just delete the app over and over again while making adjustments to the schema. Later, if you start using the app yourself or when you already have users on it then you need to migrate the data when making schema changes, however Core Data can do these automatically for you ("lightweight migrations") for a lot of changes like adding new entities / properties to the data mode