Core Data code generation



Visit the project's pretty homepage.

Here's mogenerator's elevator pitch:

mogenerator is a command-line tool that, given an .xcdatamodel file, will generate two classes per entity. The first class, _MyEntity, is intended solely for machine consumption and will be continuously overwritten to stay in sync with your data model. The second class, MyEntity, subclasses _MyEntity, won't ever be overwritten and is a great place to put your custom logic.

Want more detail? John Blanco has authored a detailed writeup about mogenerator.

Using mogenerator

Senseful wrote up a nice summary of mogenerator's command-line options.

Version History

v1.32: Wed Jan 30 2019 download

Further history is listed in the Version History file.

  • Xcode 4 and Xmo’d compatibility

    Xcode 4 and Xmo’d compatibility

    Now that Apple is trying to force us to use Xcode 4, I'm in front of a problem: it seems Xmo'd doesn't work with this major Xcode release. Is there a solution for that out there? If not, are you planning on adding the support for Xcode 4 anytime soon? Can I help on that?

    opened by MonsieurDart 28
  • Xcode 3.2.3 not kicking off mogenerator

    Xcode 3.2.3 not kicking off mogenerator

    Running mogenerator with 3.2.3 and when I save the model I get the following error in the console.

    7/2/10 10:05:23 AM [0x0-0x5a75a7][33556] osascript: couldn't save changes to script /Developer/Library/Xcode/Plug-ins/Xmod.pbplugin/Contents/Resources/Scripts/Xmod.scpt: Permission denied

    opened by mzarra 21
  • ARC support is broken

    ARC support is broken

    The command:

    mogenerator -m PlantEditor.xcdatamodeld/PlantEditor.xcdatamodel -template-path ~/Library/Application\ Support/mogenerator —template-var arc=true

    or any variation of it (with or without template path), different order of arguments, etc. never produced ARC compliant classes. As a quick workaround I had to edit the machine.h.motemplate.

    This is true for the latest sources as well as latest official release.

    opened by tuparev 20
  • Swift support

    Swift support

    Hi. I quite confused about swift support.

    1. according this line: I should write --swift option.
    2. according link in beginning of your readme: there is no mention about swift at all.
    3. also according readme you mention that we should use --v3 option to generate in swift. There is also mention about some to-one relationships bug - is there issue related to this bug? how better to track resolution of this bug?
    4. And finally, I found, that you have swift12 branch. Is it better to build your project from this branch to use it in swift project?
    opened by skywinder 19
  • Swift: Make generated machine classes and their attributes public.

    Swift: Make generated machine classes and their attributes public.

    Swift classes in frameworks/dynamic libraries are inaccessible to clients unless they and their public API are declared public. A class may not be made public unless its superclass is also public.

    So: If you want to expose MyMogeneratedClass in a dynamic library, you must also declare _MyMogeneratedClass public. This requires hand-editing _MyMogeneratedClass.swift, which defeats the purpose of machine-generated classes.

    This revision adds the public qualifier to the class and @NSManaged properties in machine.swift.motemplate.


    A subtler implementation might add a command-line argument to suppress or otherwise refine the use of public. However:

    1. Nobody needs more command-line arguments. Ever.
    2. Risk of accidental collisions between framework and client code is small (absent in Swift).
    3. @objc methods are introspectable whether defined in Swift or Objective-C. “Unauthorized” access to private API is a ship that sailed thirty years ago. Details too numerous to state here.
    4. See the next section: You can’t unit-test a mogenerated class without making it public.


    The rake-mediated test suite in test/ passes. In my haste, I haven’t figured out whether MogenSwiftTest has anything to do with the integrity of the product. Possibly not, or not recently, as it relies on the WWDC dialect of Swift rather than that in Xcode 6.1.

    With modifications (which included a lot of public tags to expose the classes under test to the test module), the Test action yields a pass on all tests.

    opened by fritza 17
  • 1.27 asserts on -[MOGeneratorApp setModel:] (current rev is OK)

    1.27 asserts on -[MOGeneratorApp setModel:] (current rev is OK)

    The latest public release (1.27) asserts in -[MOGeneratorApp setModel:] for a stupid-simple xcdatamodeld. This is fixed in the latest revision, (e8a05a316), but I have to explain mogenerator to a readership that can't be trusted to clone a Git repo.

    Supplying the .xcdatamodel inside the .xcdatamodeld cures the problem in 1.27.

    The notes for 1.27 advertise the handling of .xcdatamodeld as an enhancement in that release.

    Can a 1.28 possibly be packaged-up in the next few weeks?

    Always recognizing I may be doing something boneheaded.

    Sample project in Dropbox.

    $ mogenerator -v
    mogenerator 1.27. By Jonathan 'Wolf' Rentzsch + friends.
    $ pwd
    $ ls
    Base.lproj          KillMeMogenerator-Info.plist
    Images.xcassets         KillMeMogenerator-Prefix.pch
    KMGAppDelegate.h        Model.xcdatamodeld
    KMGAppDelegate.m        en.lproj
    KMGViewController.h     main.m
    $ mogenerator --model Model.xcdatamodeld/
    Assertion failed: (model), function -[MOGeneratorApp setModel:], file /Users/wolf/code/github/mogenerator/mogenerator.m, line 681.
    Abort trap: 6
    $ mogenerator --model Model.xcdatamodeld/Model.xcdatamodel/
    4 machine files and 4 human files generated.
    opened by fritza 17
  • Can't add object to ordered set

    Can't add object to ordered set

    My VectorLayer object has an ordered to-many relationship to VectorStroke named strokes. I cannot seem to add a VectorStroke to my VectorLayer without it crashing.

    I've tried adding a VectorStroke to the VectorLayer directly with the following results: [vectorLayer addStrokesObject:vectorStroke];

    * Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '* -[NSSet intersectsSet:]: set argument is not an NSSet'

    And I've tried using the strokesSet property and got the following results: [vectorLayer.strokesSet addObject:vectorStroke];

    *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'NSManagedObjects of entity 'VectorLayer' do not support -mutableSetValueForKey: for the property 'strokes''

    Am I doing something wrong or is this a bug?

    opened by pip8786 17
  • swift: fix incorrect override on class methods

    swift: fix incorrect override on class methods

    These two class methods are synthesized by mogenerator, so they should only override when hasSuperentity, not when hasCustomSuperentity (which also returns true when a custom base class is specified).

    Fixes #253

    opened by protocool 15
  • Release 1.28

    Release 1.28

    This great project seems a bit dead, let's try to get a little bit of life back into it. How can we get 1.28 released?

    I don't think that we have to worry too much about backwards compatibility, people can always use the old version to generate their files.

    So where do we start?

    opened by yvbeek 15
  • 1.22 uses GCC 4 which is unavailable under Xcode 4

    1.22 uses GCC 4 which is unavailable under Xcode 4

    HEAD appears to use clang, and builds fine under Xcode 4, but I’d prefer to keep the homebrew distro using tagged, stable releases.

    Ergo: is 1.23 around the corner?

    opened by robrix 15
  • PONSO: NSSet-based templates, improved inverse relationship logic

    PONSO: NSSet-based templates, improved inverse relationship logic

    Three major changes in this one:

    Inverse relationships are more Core Data like

    In the case where you have, for example:

    Employee has one Department
    Department has many Employees

    If you tried to do: [anEmployee setDepartment: aDepartment]; It would fail to set the inverse "many" relationship (i.e add anEmployee to the employees array). I've made a few changes to the PONSO template to correct this behaviour. I've taken steps to ensure that it won't infinite loop!

    Fixed a memory leak when the "many" relationship in a one-to-many is Transient

    In the case above, if it was configured as such:

    Employee has one Department [Non-Transient]
    Department has many Employees [Transient]

    Employees would be added to an NSArray, and by default, NSArrays retain any objects added to them. This results in an unexpected memory leak (since one would assume that making it transient, like for the "one" side, causes it to be "assigned"). I've fixed this by using a trick when creating the NSMutableArray (or NSMutableSet, see below) - using CFArrayCreateMutable, you can set the "retain" and "release" functions to NULL to prevent it from calling retain and release on added objects. Since this makes use of the Toll-free bridge, it will cause issues with ARC projects.

    NSSet-based PONSO Templates

    I've also added a sub-directory to the PONSO templates folder which is basically the same as the NSArray ones except it uses NSSet instead of NSArray. This is particularly useful, since along with my changes to inverse relationships, with NSArrays, the following code would result in unexpected behaviour: [anEmployee setDepartment: aDepartment]; [anEmployee setDepartment: aDepartment]; You'd end up with the employees array containing anEmployee twice, which may not be what the developer was expecting. Using the NSSet-based templates gets around this issue since NSSets only accept unique objects.

    opened by tyrone-sudeium 14
  • Wiki for Template Variables - abstract should read isAbstract

    Wiki for Template Variables - abstract should read isAbstract

    Expected Behavior

    The Wiki for Template Variables / NSEntityDescription lists abstract in the table.

    Actual Behavior

    The table should read isAbstract instead of abstract

    opened by paulnelsontx 0
  • Fixes for Swift to-many accessors, Swift mutableSets

    Fixes for Swift to-many accessors, Swift mutableSets

    Summary of Changes

    Machine Swift template had several long standing issues, one of which was absolutely incorrect and some that needed updates or improvements.

    Specifically, the mutable relationship accessors were not correct: they just returned a mutable copy of a set instead of returning the actual underlying mutable set provided by the APIs (and where are correctly implemented in the Obj-C code).

    Later these same accessors were used in manually written add/removeObjects accessors, which while worked was not done using underlying collections and thus less efficient. Also, these accessors are now generated by the compiler, using @NSManaged attribute. See #332 .



    opened by apparentsoft 0
  • Feature Request: MacPorts support

    Feature Request: MacPorts support


    In addition to Homebrew, could you support MacPorts as a distribution method?

    Homebrew is widely used by freelancers but is a complete mess to use at scale with managed fleet of Macs. And the Homebrew team repeatedly shown disrespect to Apple guidelines leading their system to break other software on the device.

    Homebrew has a long history of issue proving it's not an enterprise grade distribution system unlike MacPorts.

    With support for MacPorts, Mac Admins would also be able to generate a pkg from your port to distribute it via fleet management solution, without the need of a port solution on the endpoint.

    That would be a really great addition to the long standing reference mogenerator.

    And thanks a lot for your work!

    opened by ygini 1
  • Merge Swift42 branch changes

    Merge Swift42 branch changes

    Summary of Changes

    This incorporates a variety of updates to generated Swift code. Objective-C generated code is not affected by this PR. Changes are listed in the updated README and below.

    This does not include Codable support for NSManagedObject subclasses, which has been shelved for now.


    • [NEW] Update Swift templates for better Swift style (Aleksandar Vacić)

    • [FIX] Fixed invalid call of NSManagedObject.fetchRequest() (Vincent Esche)

    • [NEW] Add support for URI and UUID attribute types (Trevor Squires)

    • [NEW] Expose information when custom type is set through userInfo (Aleksandar Vacić)

    • [NEW] Add Codable property support via a new attributeCodableTypeName user info key (Tom Harrington)

    • [CHANGE] Nullability annotations for generated primitive accessors (Michael Babin)

    • [FIX] Support for “Uses Scalar Type” (Rok Gregorič)

    • [FIX] Swift 3 NSData to Data (Christopher Rogers)

    • [FIX] Add specialized fetchRequest() func to Swift's machine generated files (0xpablo)

    • [FIX] Correct Swift machine template for singleton (fetchOne…) fetch request results (Warren Burton)

    • [FIX] Expose allAttributes and allRelationships (Trevor Squires)

    opened by atomicbird 4
  • generate NSFetchRequest without executing it

    generate NSFetchRequest without executing it

    Feature Request

    I'd like to see the template create +fetch<Foo>Request methods that return an NSFetchRequest so that I can modify it, in code, before executing it.

    Additional Information

    I have a modified template pair that does this. Are you interested in a PR? Should I wrap it in a template variable (to optionally disable/enable it)?

    opened by halmueller 3
  • Use scalar properties for primitive data types

    Use scalar properties for primitive data types

    Hi there,

    the generated classes do have the NSNumber type for bool an double values. In xcode there is a way to check "Use scalar properties for primitive data types" - is there a way to realize this with mogenerator, too?

    I want to use model.isCkecked = YES to set the value for a bool.

    opened by darkwood-studios 3
  • 1.32(Jan 31, 2019)

    Source code(tar.gz)
    Source code(zip)
  • 1.31(Oct 3, 2016)

    Source code(tar.gz)
    Source code(zip)
    mogenerator-1.31.dmg(133.56 KB)
  • 1.30.1(Apr 7, 2016)

  • 1.30(Mar 22, 2016)

    Thanks to lieutenant Justin Williams for helping with this release.

    • [NEW] Official bundled Swift 2 templates. (Justin Williams 1 2)
    • [NEW] "Modern" Objective-C and Swift is default. Apple has made it exceptionally difficult to target older versions of OS X and iOS, so we've given up. The grand --v2 experiment, which I loved, has been killed (the option will still be accepted to not break existing scripts but is now a no-op). From now on if you need to target an older OS, use an older mogenerator. Sorry. (Justin Williams)
    • [NEW] Generate Objective-C Lightweight Generics. (rentzsch)
    • [NEW] Generate instancetype. (Justin Williams)
    • [NEW] Generate nullability attributes for Objective-C machine templates (NS_ASSUME_NONNULL_BEGIN/nullable). (Justin Williams)
    • [NEW] mogenerator project is now using Travis CI. Travis automatically builds and runs mogenerator's test suite on each commit, reporting the results, making it easier+faster to process Pull Requests. (rentzsch)
    • [NEW] Change of branch philosophy: master used to be the "stable" branch. Now it's the branch we're going to land incoming Pull Requests. Pull Requests will be accepted onto master pretty freely, Travis will help catch breaking changes. I want to reduce latency and friction for folks to help out with mogenerator. Related reading: Drew Crawford's Conduct unbecoming of a hacker. (rentzsch)
    • [NEW] Specifying --template-var scalarsWhenNonOptional=true will have mogenerator generate only scalar properties for non-optional entity scalar attributes. For example, consider an age attribute. Without this option, mogenerator will generate two properties: @property (…) NSNumber *age and @property (…) uint16_t ageValue. With this option, only @property (…) uint16_t age would be generated, simplifying things since the age attribute can never be nil. (Mr Anonymous)
    • [CHANGE] Replace Mike Ash-style constant structures in favor of more ARC-friendly NSObject subclasses. Should be source-compatible with with Mike Ash-style. (Justin Williams)
    • [FIX] You can specify an entity's module in Xcode's Core Data Model editor. However, when specifying the current module, the entity class name is prefixed with a period, resulting in an invalid class name. This period is now suppressed. (Saul Mora)
    • [FIX] momcom: NSPropertyDescription's optional wasn't being set correctly. issue 286 (Matthias Bauch)
    • [FIX] override and explicitly include xcshareddata in .gitignore and add the default shared schemes. This fixes the problem where xcodebuild would fail with an The project 'mogenerator' does not contain a scheme named 'mogenerator' error until you first opened it in Xcode. (rentzsch)
    • [FIX] Generated indentation. (Markus Chmelar 1 2)
    • [FIX] Use DERIVED_FILE_DIR instead of TMPDIR. (Jonathan MacMillan)
    • [CHANGE] Move the constant structures to the end of the machine header file. It's just uninteresting support code. (rentzsch)
    • [MODERNIZE] MiscMerge: switch to Objective-C Modules. (Justin Williams)
    • [MODERNIZE] Use instancetype internally. (Justin Williams)
    • [MODERNIZE] 64-bit only. (Justin Williams)
    • [MODERNIZE] Replace nsenumerate macro with (Justin Williams)
    • [MODERNIZE] MiscMerge: encode all source files as UTF8. (Justin Williams)
    • [MODERNIZE] Set minimum deployment target to 10.8. (Justin Williams)
    • [MODERNIZE] Replace RegexKitLite with NSRegularExpression. (Justin Williams)
    • [MODERNIZE] Replace arrayWithObjects and dictionaryWithObjectsAndKeys with literals. (Markus Chmelar 1 2)
    • [MODERNIZE] Replace objectAtIndex:0 with firstObject. (Markus Chmelar)
    • [REMOVED] //validate machine comments. They were just guides on writing your own validation methods and aren't worth the code clutter. (Justin Williams)
    • [REMOVED] Xmo'd. It hasn't worked for a very long time and I have no immediate plans on putting in the time to get working again. (Justin Williams)
    Source code(tar.gz)
    Source code(zip)
    mogenerator-1.30.dmg(134.65 KB)
  • 1.29(Aug 20, 2015)

    Much thanks to lieutenants Tom Harrington and Justin Williams for handling this release.

    Source code(tar.gz)
    Source code(zip)
    mogenerator-1.29.dmg(243.15 KB)
  • 1.28(Sep 11, 2014)

    • [NEW] --v2 argument. I wanted to enable ARC by default, but decided to take it a step further (while not breaking existing scripts). The new --v2 argument is basically semantic versioning for tool arguments.

      So now instead of this:

      mogenerator --model MyDataModel.xcdatamodeld \
          --template-var arc=true \
          --template-var literals=true \
          --template-var modules=true

      You can write this:

      mogenerator --v2 --model MyDataModel.xcdatamodeld

      Internally these invocations are equivalent, but new scripts and manual invocations should use the --v2 variant.

      I recommend putting the --v2 in front of the rest of the arguments to call attention to the versioned context of the following arguments.

      This mechanism should allow mogenerator to continue to supply sensible defaults into the future as well. Perhaps --v3 will generate Swift by default. Speaking of which…

    • [NEW] Experimental Swift code generation. Unfortunately basic Core Data functionality (to-one relationships) is broken on 10.9, but we can still try writing theoretically-correct Swift code. Perhaps a future version of mogenerator will supply the needed work-around code for you. (Alexsander Akers, afrederick1, Piet Brauer, rentzsch, Chris Weber, Markus Chmelar, Brent Royal-Gordon)

    • [NEW] Ordered relationships actually work. OMG. I have them working in a new separate OS X test app, even though mogenerator's test dir fails. I still haven't figured out why, but I'm not holding this back. (Daniel Tull, Joshua Greene, Dave Wood, Jonathan del Strother)

    • [NEW] Custom scalar types. Specify attributeValueScalarType for the name of the property's custom type and additionalHeaderFileName if you need to bring in an additional header file for compilation. With this, mogenerator supports C-style and JREnum-style enums. (Quentin ARNAULT)

    • [NEW] Remove unnecessary empty lines in the generated files. (Stephan Michels)

    • [NEW] Ability to forward-declare @protocols for i.e. transformable types. Specify them via a comma delimited string in the entity's user info under the attributeTransformableProtocols key. (Renaud Tircher)

    • [NEW] Generate *UserInfo key/value pairs as const structs. (Jeremy Foo, rentzsch)

    • [NEW] --template-var literals which, when enabled, generates Obj-C literals. (Brandon Williams, Thomas van der Heijden, rentzsch)

    • [NEW] Specify --template-var modules=true option to avoid treating #import as an import of module 'CoreData' [-Wauto-import]" warning. (Daniel Tull)

    • [NEW] Unsigned integers are generated when a property's minimum is set to 0 in the Xcode modeler. (Dan Pourhadi)

    • [NEW] Add support for setting command-line options via a JSON config file. (Simon Whitaker)

    • [NEW] Add file. It's now even easier to contribute to mogenerator :) (rentzsch)

    • [NEW] Add MIT LICENSE file to make it clear templates are under the same license. (rentzsch)

    • [CHANGE] Suppress generation of -setPrimativeType: method. issue 16. (rentzsch)

    • [CHANGE] Add a warning when skipping an attribute named 'type'. (Simon Whitaker)

    • [CHANGE] Add explicit atomic to sooth -Weverything. (Daniel Tull)

    • [CHANGE] iOS 8 changes objectID from a getter into a property, resulting in a warning. Templates updated to match. (Ryan Johnson)

    • [FIX] Support newly-created models when --model=*.xcdatamodeld. issue 137. (Sergey)

    • [FIX] Minor warning fix, 64->32 truncation, format strings. (Sean M)

    • [FIX] Machine headers always #imports their superentity if present. (David Aspinall)

    • [FIX] Fetch requests whose predicate LHS specifies a relationship. issue 15. (rentzsch)

    • [FIX] Don't emit empty *UserInfo structs. (Jeremy Foo 1 2)

    • [FIX] Don't emit empty *Attributes, *Relationships, and *FetchedProperties structs. (Daniel Tull)

    • [FIX] MOIDs subclass their superentity (instead of just always inheriting from NSManagedObject). (Daniel Tull)

    • [FIX] Don't touch aggregate include files if the content didn't change. (Stephan Michels)

    • [FIX] Don't attempt to #import "NSManagedObject.h" even in the face of weird (corrupted?) model files. issue 42. (rentzsch)

    • [TEST] Escape spaces in mogenerator build path. (Daniel Tull)

    Source code(tar.gz)
    Source code(zip)
    mogenerator-1.28.dmg(208.17 KB)
JSON to Core Data and back. Swift Core Data Sync.

Notice: Sync was supported from it's creation back in 2014 until March 2021 Moving forward I won't be able to support this project since I'm no longer

Nes 2.5k Dec 31, 2022
Eliminate your Core Data boilerplate code

SSDataKit There is a lot of boilerplate code required to write a Core Data application. This is annoying. In pretty much everything I've written since

Sam Soffes 456 Dec 21, 2022
Super awesome Swift minion for Core Data (iOS, macOS, tvOS)

⚠️ Since this repository is going to be archived soon, I suggest migrating to NSPersistentContainer instead (available since iOS 10). For other conven

Marko Tadić 306 Sep 23, 2022
A powerful and elegant Core Data framework for Swift.

A powerful and elegant Core Data framework for Swift. Usage Beta version. New docs soon... Simple do that: let query = persistentContainer.viewContext

null 782 Nov 6, 2022
CloudCore is a framework that manages syncing between iCloud (CloudKit) and Core Data written on native Swift.

CloudCore CloudCore is a framework that manages syncing between iCloud (CloudKit) and Core Data written on native Swift. Features Leveraging NSPersist

deeje cooley 123 Dec 31, 2022
Unleashing the real power of Core Data with the elegance and safety of Swift

Unleashing the real power of Core Data with the elegance and safety of Swift Dependency managers Contact Swift 5.4: iOS 11+ / macOS 10.13+ / watchOS 4

John Estropia 3.7k Jan 9, 2023
JSQCoreDataKit - A swifter Core Data stack

JSQCoreDataKit A swifter Core Data stack About This library aims to do the following: Encode Core Data best practices, so you don't have to think "is

Jesse Squires 596 Dec 3, 2022
JustPersist is the easiest and safest way to do persistence on iOS with Core Data support out of the box.

JustPersist JustPersist is the easiest and safest way to do persistence on iOS with Core Data support out of the box. It also allows you to migrate to

Just Eat 167 Mar 13, 2022
QueryKit, a simple type-safe Core Data query language.

QueryKit QueryKit, a simple type-safe Core Data query language. Usage QuerySet<Person>(context, "Person")

QueryKit 1.5k Dec 20, 2022
A minimalistic, thread safe, non-boilerplate and super easy to use version of Active Record on Core Data.

Skopelos A minimalistic, thread-safe, non-boilerplate and super easy to use version of Active Record on Core Data. Simply all you need for doing Core

Alberto De Bortoli 235 Sep 9, 2022
HitList is a Swift App shows the implementation of Core Data.

HitList HitList is a Swift App shows the implementation of Core Data. It is the demo app of Ray Wenderlich's tech blog. For details please reference G

Kushal Shingote 2 Dec 9, 2022
A synchronization framework for Core Data.

Core Data Ensembles Author: Drew McCormack Created: 29th September, 2013 Last Updated: 15th February, 2017 Ensembles 2 is now available for purchase a

Drew McCormack 1.6k Dec 6, 2022
Super Awesome Easy Fetching for Core Data!

MagicalRecord In software engineering, the active record pattern is a design pattern found in software that stores its data in relational databases. I

Magical Panda Software 10.9k Dec 29, 2022
A type-safe, fluent Swift library for working with Core Data

Core Data Query Interface (CDQI) is a type-safe, fluent, intuitive library for working with Core Data in Swift. CDQI tremendously reduces the amount o

null 31 Oct 26, 2022
A feature-light wrapper around Core Data that simplifies common database operations.

Introduction Core Data Dandy is a feature-light wrapper around Core Data that simplifies common database operations. Feature summary Initializes and m

Fuzz Productions 33 May 11, 2022
The Big Nerd Ranch Core Data Stack

BNR Core Data Stack The BNR Core Data Stack is a small Swift framework that makes it both easier and safer to use Core Data. A better fetched results

Big Nerd Ranch 561 Jul 29, 2022
100% Swift Simple Boilerplate Free Core Data Stack. NSPersistentContainer

DATAStack helps you to alleviate the Core Data boilerplate. Now you can go to your AppDelegate remove all the Core Data related code and replace it wi

Nes 216 Jan 3, 2023
Example repo of working with Core Data in a SwiftUI application

CoreData in SwiftUI This repository serves many purpose. But mostly so I can experiment with Core Data in SwiftUI, and also so I can use it show my ap

Donny Wals 4 Jan 30, 2022
This project server as a demo for anyone who wishes to learn Core Data in Swift.

CoreDataDemo This project server as a demo for anyone who wishes to learn Core Data in Swift. The purpose of this project is to help someone new to Co

null 1 May 3, 2022